On 27/06/2019 09:29, Stephane Chazelas wrote:
2019-06-27 08:59:29 +0100, Harald van Dijk:
[...]
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.
I hate to revisit this thread, but I found out today that this was very
much an intentional decision and the resolution of bug 1234 goes
completely contrary to that intent.
Quoting https://unix.org/whitepapers/shdiffs.html:
However, the command:
find . -name 'a(b*' -print
did work.
Now, this form requires escaping of the shell character to avoid side
effects from implementation extensions:
find . -name 'a\(b*' -print
This makes it as explicit as it can possibly be that the wording had
always been intended to be interpreted as exactly what it said, that
metacharacters *do* require escaping here and have required so ever
since the first version of POSIX, that it was intentional that an
unescaped '(' in a find -name pattern may result in other behaviour than
matching a literal '('.
Cheers,
Harald van Dijk
