-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Reinstate failglob behaviour for most commands #2719
Conversation
Without running this: I think I'd be okay with this behavior (it's basically what I suggested). At the very least you'll want to look at test5, which fails because you also print the error message for Otherwise it's worth discussing, especially:
Of course both of these could be left out - we could tell people to use variables if they want that. And one thing I'll have to test is if the error message is suppressable. |
Thanks for the review! Yes, I read your posts on the matter, and the last one inspired me to try if this was possible. I'm looking into the case failure, but I think it's bedtime for me now. |
Now I get it, This commit accidentally "fixes" it by disallowing the syntax — what I should do is modify the expected result. |
Expand globs to zero arguments (nullglob) only for set, for and count. The warning about failing globs, and setting the accompanying $status, now happens regardless of mode, interactive or not. It is assumed that the above commands are the common cases where nullglob behaviour is desirable. More importantly, doing this with `set` is a real feature enabler, since the resulting empty array can be passed on to any command. The previous behaviour was actually all nullglob (since commit cab115c), but this was undocumented; the failglob warning was still printed in interactive mode, and the documentation was bragging about failglob behaviour.
test5 is now fixed by expecting this error output:
Now, I'm struggling to reproduce the "bind.expect" failure in the clang test. |
The bind.expect failure is a gnarly timing issue due to ASAN (I think!), though we've also had trouble reproing it so I may easily be wrong. Thanks for being conscientious and you can ignore that one. |
# Lists the .foo files, or warns if there aren't any. | ||
|
||
set foos *.foo | ||
if test (count $foos) -ge 1 |
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 test is actually unnecessary - count will return 1 if given no arguments (and 0 otherwise), so if count $foos >/dev/null
works just as well. As would if set -q foos[1]
.
I actually can't find anything wrong with the behavior here. @ridiculousfish: I'd like to merge this and believe we can add any other nullglob command or syntax later. Okay? |
Reviewed, looks most excellent. Merged with rebase as 62b76b2 . Thanks!! |
Thank you guys, I'm delighted. |
Expand globs to zero arguments (nullglob) only for set, for and count.
The warning about failing globs, and setting the accompanying $status,
now happens regardless of mode, interactive or not.
It is assumed that the above commands are the common cases where
nullglob behaviour is desirable.
More importantly, doing this with
set
is a real feature enabler,since the resulting empty array can be passed on to any command.
The previous behaviour was actually all nullglob (since commit
cab115c), but this was undocumented;
the failglob warning was still printed in interactive mode,
and the documentation was bragging about failglob behaviour.