2019-06-27 08:59:29 +0100, Harald van Dijk: [...] > > 2 is slightly more portable, but even in those shells where it > > does that, that's not because they implement \ processing the > > way POSIX seems to specify it, and all do it a different way. > > I'm not opposing POSIX *allows* a \ in an unquoted word > > expansion to have a special meaning when it's preceding *, ? and > > [ as that's what several implementations do and it's not > > breaking that many common shell usages. > > It should not be limited to when it's preceding any specific character, > though. That is something no shell has done. Shells currently vary in > whether backslash can function as an escape character during pattern > matching, but when it can, it does not depend on which character follows it.
That's what zsh does (and did before POSIX). That's the intention, but as mentioned earlier it's quite buggy (https://www.zsh.org/mla/workers/2019/msg00465.html). And in ksh93, again \d is not an escaped d but matches a digit. But I agree we need to allow \ to be treated specially when in front of a non-wildcard as that's what several implementations do. But only when pattern matching is involved. That includes pathname expansion, but pathname expansion should only be performed when a words contains unquoted ?, [ or * (not "(" as even ksh93 doesn't do it). Also note that in netbsd8.1 sh, as already pointed out: In: var1='\foo/bar*' ls -d -- $var1 var2='\foo-bar*' ls -d -- $var2 \ is only considered an escape operator in the var2 case as the var1 case splits the word on / and the first part doesn't contain an unquoted [, ?, *. That would still be allowed if we made it unspecified what \x does when a word contains an unquoted */?/[. That also applies to: var='\*' ls -d -- $var [...] > If there is no fnmatch() implementation that behaves that way, then agreed > that it makes sense to just specify that. That pax example in the rationale > should then also be changed to not escape any parenthesis. > > What did this pax example come from, though? Was that based on a real pax > implementation that did have special treatment of parentheses, not just an > invention? [...] That's something I also wondered. I do have a vague recollection that some early glob() implementations were actually calling "sh" to expand globs (so for instance glob("*`reboot`*") would reboot (which is currently allowed by the spec as ` is a shell special character). Could it be linked to that? I wouldn't expect it to apply to fnmatch() though. Or maybe I'm confusing with perl globs that used to call csh. -- Stephane
