On 21/10/18 18:13, Vincent Lefevre wrote: > Package: coreutils > Version: 8.30-1 > Severity: normal > Tags: upstream > Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33113 > > I get the following with ls (GNU coreutils) 8.30. > > zira% touch a=b a=b\&c > zira% ls a=b* > 'a=b' 'a=b&c' > zira% ls -b a=b* > a=b a=b&c > zira% ls -F a=b* > 'a=b' 'a=b&c' > zira% ls -bF a=b* > a\=b a\=b&c > > AFAIK, the = character is not a shell metacharacter (except with zsh > but only in the first position), thus does not need to be quoted. > > Moreover, while & is not a metacharacter, it is a special character > that should be quoted for practical reasons. > > In particular, this inconsistency with -bF makes a\=b&c unusable by > copy-paste, as a\=b&c can't be used directly in a shell command, and > 'a\=b&c' is not OK either. > > Note: Such filenames with = and & can be produced by "wget -r". >
The reason \= is quoted with -bF is to distinguish socket names that end in =. An edge case indeed, though the issue is not particular to '=', but all of the classifier chars. -b does not support copy and paste at the shell directly. For that, the default (--quoting-style=shell-escape) is really the only one directly usable. Note with `set -k` equals is significant in any arg and so needs quoting. cheers, Pádraig
