On 26/03/2018 15:34, Martijn Dekker wrote:
Op 26-03-18 om 14:12 schreef Harald van Dijk:
On 26/03/2018 13:57, Martijn Dekker wrote:
I don't see any inconsistency. Expansions are consistently treated
differently within 'case' than outside it. Among other things,
expansions within 'case' are *not* subject to pathname expansion; it's
string pattern matching using glob patterns, which is something
completely different.
It's not something completely different. Pathname expansion is defined
in terms of pattern matching (the pattern matching used in e.g. case
statements), plus a specific set of differences. See 2.6.6 Pathname
Expansion:
After field splitting, if set -f is not in effect, each field in the
resulting command line shall be expanded using the algorithm described
in Pattern Matching Notation, qualified by the rules in Patterns Used
for Filename Expansion.
That specific set of differences, 2.13.3 Patterns Used for Filename
Expansion, doesn't include different treatment of backslashes.
I see your point now. You're absolutely right.
Hmmm...
If we backslash-escape a glob character, '?':
$ touch '_foo?bar_'
$ testshells -c 'p='\''*o\?b*'\''; printf %s $p'
The backslash is correctly honoured by:
bash 2.05b through git: _foo?bar_
dash 0.5.5.1: _foo?bar_
dash-hvdijk: _foo?bar_
zsh as sh: _foo?bar_
The backslash is *not* honoured by:
dash 0.5.6 through 0.5.9.1: *o\?b*
ksh93: *o\?b*
mksh/lksh: *o\?b*
yash -o posix: *o\?b*
And not by dash 0.5.4. Like I wrote, dash 0.5.5 had some bugs that were
fixed in 0.5.6, which mostly restored the behaviour to match <0.5.5.
And if we backslash-escape a non-glob character, 'b':
$ touch '_foo?bar_'
$ testshells -c 'p='\''*o?\b*'\''; printf %s $p'
The backslash is correctly honoured by:
bash 2.05b through git: _foo?bar_
dash 0.5.5.1: _foo?bar_
dash-hvdijk: _foo?bar_
The backslash is *not* honoured by:
dash 0.5.6 through 0.5.9.1: *o\?b*
ksh93: *o\?b*
mksh/lksh: *o\?b*
yash -o posix: *o\?b*
zsh as sh: *o\?b*
Also not by dash 0.5.4.
Funny how these results are different from the results I get when doing
the same test with 'case' pattern matching. As you point out, they are
supposed to be subject to the same rules with some modifications *not*
including backslash parsing. So the results should at least be identical
for each shell.
So yes, dash is inconsistent. But given what POSIX says, I think dash
should probably go back to honouring the backslash for pathname
expansion as it did in 0.5.5.1 and does in your fork.
Maybe you should argue the case with the Austin Group. It would be nice
to get clarification on the issue.
I don't think 0.5.5 should be taken as the reference point for historic
dash behaviour when older versions disagree with it as much as the newer
ones.
As for my patches, that was by accident and doesn't work reliably. When
the shell sees no metacharacters, pathname expansion is bypassed, and
backslash isn't considered a metacharacter. Which got me to my original
example of /de\v: there are no metacharacters in there, so the shell
doesn't look to see if it matches anything. Which seems highly
desirable: the shell shouldn't need to hit the file system for words not
containing metacharacters. The only way then to get consistent behaviour
is if the backslash is taken as quoted, so I'm not tempted to argue for
the behaviour you're hoping for, sorry. :)
And remember, personal playground, lots of disclaimers about bugs. Don't
consider it a fork, I don't treat it as a separate project, it's just
that dash is a nice program for me to play around with. When I noticed
the difference, that's what prompted me to ask the question in the first
place. I suspected the intent for dash was to treat it as quoted, but I
was hoping for verification.
Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
