New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate builtin test's one- and zero-argument modes #10365
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -79,6 +79,8 @@ pub mod categories { | |
|
||
(warning_path, "warning-path", "Warnings about unusable paths for config/history (on by default)", true); | ||
|
||
(deprecated_test, "deprecated-test", "Warning about using test's zero- or one-argument modes (`test -d $foo`), which will be changed in future."); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fine by me. Given what I know I'm fine with enabling this warning now already There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be clear: As this PR stands, by default, it will not do anything. If the warning is enabled, it will show the warning, the exit code will remain. If the feature flag is enabled, the exit code will change. The end goal is to have the behavior that I consider best, which is that The plan is to stage this carefully:
That means we have a step where there's a warning but no change in the exit code (by default), but it's only a step. I do not consider "warn about bad behavior but keep it" to be a good final outcome, I would like to go further and end at "okay behavior". But I also believe that giving people some time where they know the change is coming without already throwing warnings at them - which is, as we have discussed, itself a breaking change for many uses, even if it is easy to revert. That's why I would like to have that first step. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think everything that can be said has been said already. You go ahead. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
yeah you're right that announcing things in release notes before we change anything is the proper way to do it. |
||
|
||
(config, "config", "Finding and reading configuration"); | ||
|
||
(event, "event", "Firing events"); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
# RUN: %fish %s | ||
# | ||
# Tests for the posix-mandated zero and one argument modes for the `test` builtin, aka `[`. | ||
|
||
test -n | ||
echo $status | ||
#CHECK: 0 | ||
|
||
test -z | ||
echo $status | ||
#CHECK: 0 | ||
|
||
test -d | ||
echo $status | ||
#CHECK: 0 | ||
|
||
test "foo" | ||
echo $status | ||
#CHECK: 0 | ||
|
||
test "" | ||
echo $status | ||
#CHECK: 1 | ||
|
||
test -z "" -a foo | ||
echo $status | ||
#CHECK: 0 | ||
|
||
set -l fish (status fish-path) | ||
echo 'test foo; test; test -z; test -n; test -d; echo oops' | $fish -d 'deprecated-*' >/dev/null | ||
#CHECKERR: test: called with one argument. This will return false in future. | ||
#CHECKERR: Standard input (line 1): | ||
#CHECKERR: test foo; test; test -z; test -n; test -d; echo oops | ||
#CHECKERR: ^ | ||
#CHECKERR: test: called with no arguments. This will be an error in future. | ||
#CHECKERR: Standard input (line 1): | ||
#CHECKERR: test foo; test; test -z; test -n; test -d; echo oops | ||
#CHECKERR: ^ | ||
#CHECKERR: test: called with one argument. This will return false in future. | ||
# (yes, `test -z` is skipped because it would behave the same) | ||
#CHECKERR: Standard input (line 1): | ||
#CHECKERR: test foo; test; test -z; test -n; test -d; echo oops | ||
#CHECKERR: ^ | ||
#CHECKERR: test: called with one argument. This will return false in future. | ||
#CHECKERR: Standard input (line 1): | ||
#CHECKERR: test foo; test; test -z; test -n; test -d; echo oops | ||
#CHECKERR: ^ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good change.
One alternative is to keep returning the same exit code as today, but only print the error. This way we wouldn't really need a feature flag. I'm fine with either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not a bad idea. That could be our "depreciation phase".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way this is used, errors and warnings are often already breaking - if your prompt or worse a binding suddenly prints a warning that makes you want to avoid it, and so you would want to fix it immediately.
This isn't e.g. python, where you can add warnings that, for the most part, will be logged away with a script's output. The context of interactive use makes this different. (and for scripted use, stderr needs to be redirected and read pretty often, it's not separated enough)
That means printing an error strikes me as a bad idea without a feature flag.
Additionally "the same exit code as today" means that
test -z
returns true. This would mean thattest -z
returns true while printing an error.Of course erroring out for all single-argument calls instead of allowing
test -n
andtest -z
is a possibility, but I would want to have it behind a feature flag.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correction, we'd still want a feature flag