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
change how bare {}
is handled so find -exec {}
isn't broken
#1109
Comments
I believe this is a duplicate of #354. |
@glitchmr well, I'm not saying fish should get rid of brace expansion in general, just the case of empty braces. Basically, having the same behavior as bash here might be good, given that |
Now that I look into it, empty brace expansion doesn't work like other brace expansions (and I already assumed they are really buggy before...). Assuming we have following function (as alternative to brace expansions - it doesn't work with newlines or globs, but other than that, it works like brace expansions): function list
for elem in $argv
echo $elem
end
end If we have one or two elements, this function and brace expansion work identically.
However, this is not the case with empty brace expansion, as empty brace expansion expands to empty string, not an empty list.
However, let's assume that we expand empty array.
In my opinion, |
@glitchmr cool, I like that reasoning. thanks for looking into it! |
+1. I found this behaviour in fish quite bewildering -- and there certainly isn't value in having {} expand to nothing. If nothing else, at least replace the generic error message for a special error message for find - but it's probably easier to just fix the parser. |
There is a potential value in having On a related note, |
I'd be happy with either of these solutions:
Seems like the first option is probably the better way to go. Basically the current failures of |
Standard commands written for bash (without variables or scripting) can usually be pasted into fish without modification - which is an awesome feature. The curly brace thing is one of the few cases where this breaks down - and Anyway, if opting for the more helpful error message, |
We could certainly make the literal token |
It seems like the zero-argument {} and single-argument {foo} braces are simultaneously the most commonly typed and the least useful expansions in fish. bash and zsh also don't expand these, and presumably have survived the fallout from eval'ing strings. I think on balance making both That may be because I personally never use brace expansion, so I'm not attached to the syntax. If there is a heavy user please weigh in! |
@ridiculousfish I thought you intentionally expanded Personally, I'm in favor of making |
I realized that
(i.e., delete all files in subdirectories of the working directory) will perform the following in fish:
...while it works as intended in bash/zsh. This is similar to what I raised before, I think it strengthens the case to give a practical example of something someone could do, rather than my vague speculation about possible nasty consequences.
Not expanding is looking better and better. |
@jbarlow83 Eek. I am very much in favor right now of making |
Huh? Fish expands that to |
You are right about |
We could just drop the whole brace expansion syntax if
Suggestion:
I'm saying this as a heavy-user of brace expansion, because the command, not syntax principle tends to be more powerful. |
Duplicate of #434, though both titles are just special cases of a general problem: Brace expansion is parsed in an unintuitive (for bash/zsh users) manner. |
Note that brace expansion was introduced by csh. Csh (back in the end of the 70s) explicitly made a documented special case for All other shells that implemented brace expansion thereafter (tcsh, ksh, zsh, bash, yash at least) copied that behaviour ( I can't imagine anyone relying on
|
See also issue #3002. It's always dangerous to change long established behavior. But in this particular case I think it is warranted. The |
I agree that is a mistake in fish's design that should be corrected. Tab completion is great, but does not help with people converting scripts or copy-pasting command lines. Here's an example of a safe bash command that turns into find . -type d -exec rm -f {}/* \; # do not do this in fish |
That one works the same in csh/tcsh (the original implementation of brace expansion) as in fish though. In csh, only Also note that |
It seems like we're all in favor of making {} expand to |
Since that's the current behavior I assume you meant to say "making {} expand to itself." |
@ridiculousfish {} already expands to nothing; the suggestion is to make {} expand to {} since all other shells seem to that. |
Also, TBD is whether we should follow csh or bash: |
Derp, yes, I meant expand to itself. Comment corrected. Thanks. With that corrected, naively I would expect |
If you want to align with ksh/zsh/bash/yash, there's also the question of Currently in Note that there are some differences between all the ksh (ksh93, pdksh/mksh), bash, zsh and yash -o braceexpand implementations. Generally for all those, Now, there's the question of the interaction with other expansions. Except maybe in zsh and yash (which behave more like In bash, brace expansion is done very early which can cause some surprises like
(That's interpreted as
or better:
(those arithmetic and command substitutions evaluated several times) Playing with the limits of the parser there can be interesting:
In
Quoting helps in pdksh/mksh, but not ksh93:
In
One thing I noticed is that all shells (including
Another thing
(bash as well, but that's not surprising for bash) |
{}
is handled so find -exec {}
isn't broken
If we're doing a 3.0 (syntax-breaking) release, let's add this. |
Agreed, although there is the question of exactly which behavior we want. For example, csh or bash. |
I don't see how csh's behavior is useful here. We want to change the behavior for a literal Its also consistent to have That means: echo {} # prints {}
echo foo{}bar # prints foo{}bar
echo foo{a,{}}bar # prints fooabarr foo{}bar
echo foo{{}}bar # prints foo{}bar In other words, something is only a brace expansion if it matches |
So do I understand correctly that this change would have to wait for a major version to be released? |
Strictly speaking, yes. And... good news: The next fish version is planned to be 3.0. |
I ran into an edge case yesterday where I actually used the bare {} syntax - I wanted to do something to files that shared a sequence number with files of a different name but the same sequence number, so I actually used this syntax: rm file1_{(for n in (seq 20 100)
if test -e file2_$n
echo $n
end
end)} except I didn’t use Basically, even when the intended expansion of braces is an empty set, they are still useless 😃 |
This caused major annoyances with e.g. `find -exec`, and it's utterly useless - "{}" expands to nothing, so why have it at all? Fixes fish-shell#1109.
"reopening" #95
i think it's bad that simple, standard find commands fail with a perplexing error message in fish, due to its expansion of empty curly braces to empty string. e.g.:
as discussed in #95 the fix is to quote '{}' but this is kind of hard to figure out
The text was updated successfully, but these errors were encountered: