change how bare `{}` is handled so `find -exec {}` isn't broken

[hrldcpr]

"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.:

> find . -name '*.txt' -exec cat {} +
find: -exec: no terminating ";" or "+"

as discussed in #95 the fix is to quote '{}' but this is kind of hard to figure out

[sugar700]

I believe this is a duplicate of #354.

[hrldcpr]

@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 man find uses empty braces all over the place, it's confusing when it doesn't work.

[sugar700]

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.

glitchmr@tomato /> list a(list 1)
a1
glitchmr@tomato /> list a{1}
a1
glitchmr@tomato /> list a(list 1 2)
a1
a2
glitchmr@tomato /> list a{1,2}
a1
a2
glitchmr@tomato /> 

However, this is not the case with empty brace expansion, as empty brace expansion expands to empty string, not an empty list.

glitchmr@tomato /> list a(list)
glitchmr@tomato /> list a{}
a
glitchmr@tomato /> 

However, let's assume that we expand empty array.

glitchmr@tomato /> list a(list $array)
glitchmr@tomato /> list a{$array}
glitchmr@tomato /> 

In my opinion, {} is incorrectly expanded to nothing (it doesn't simply kill token). As the behavior is already unlike what could be expected (see empty array case), and it's pointless, I believe it could be killed in fish 2.2.0, to make find command work properly without escaping.

[hrldcpr]

@glitchmr cool, I like that reasoning. thanks for looking into it!

[jbarlow83]

+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.

[lilyball]

There is a potential value in having {} expand to nothing, which is consistency of behavior when generating fishscript strings to pass to eval. Similarly, {$empty} should behave the same as {} unless there's a very good reason not to.

On a related note, {a} is generally quite useless, except it's repurposed as a way to separate a {$variable}name from what follows. I found this unfortunate a long time ago as it makes using @{u} syntax in git commands quite annoying. But fish has chosen to make {a} evaluate to a, and for consistency's sake, {} should probably evaluate to the empty string instead of being left intact as the string {}.

[hrldcpr]

I'd be happy with either of these solutions:

• a more helpful error message when you run find -exec with {}
• {} not evaluating to empty

Seems like the first option is probably the better way to go.

Basically the current failures of find -exec are very confusing in fish—at first I thought find simply couldn't be used in fish, and I doubt I'm alone.

[jbarlow83]

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 find is quite widely used.

Anyway, if opting for the more helpful error message, find, and parallel both use curly braces for argument distribution in their subshells. Examples straight from the man pages of both will fail in fish. Since it's quite possible someone is writing find ... | rm -rf or parallel rm {} it would be well worth complaining if find or parallel with curly braces show up in a pipeline. sysadmins will thank you. parallel also uses {n} as well where n is an integer, for reordering arguments; not sure if find has that as well.

[lilyball]

We could certainly make the literal token {} into a parse error. I'm still mildly concerned about the possibility of a string being constructed for eval that contains it, but the find issue is probably much more common than this edge case.

[ridiculousfish]

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 {} and {a} not expand specially (echo foo{bar} outputs foo{bar}) will lead to the least amount of confusion and annoyance.

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!

[lilyball]

@ridiculousfish I thought you intentionally expanded {a} for the purposes of {$foo}bar? I swear there was an issue about this, where I complained because it interferes with Git's @{upstream} notation, but I can't find it.

Personally, I'm in favor of making {a} not expand, just like bash. Instead of {$foo}bar, people can always use something like $foo''bar.

[jbarlow83]

I realized that

find . -type d -exec rm -f {}/* \;   # do not do this in fish

(i.e., delete all files in subdirectories of the working directory)

will perform the following in fish:

rm -f /*  # don't do this anywhere

...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.

grep a{1,3} is another example where expansion will have other-than-intended effects. (fish runs the command as grep a1,3 which is probably not the regex the user wanted.)

Not expanding is looking better and better.