On 27/06/2019 10:04, Geoff Clare wrote:
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 26 Jun 2019:
Or again, forget all about it and treat the ksh93 behaviour as
non-compliant as is already the case.
I'm starting to think that this is what we should do, given the number
of oddities you have identified and the potential to break existing
applications that use parentheses in find -name, fnmatch(), etc.
The primary aim (of those of us discussing the issue in teleconferences)
in resolving bug 1234 is consistency. I was hoping that we could bring
some consistency between contexts where *(...) etc. are syntax errors in
POSIX and those where they aren't by limiting which cases can be
considered special. But that doesn't look workable now.
So here's a new proposal which just clarifies that *(...) etc. can
only be special when they would otherwise be a syntax error.
I'm not objecting, but even if you limit it to this, it's still a
change, not a clarification, no? It came as a surprise to some people,
but I do not see anything ambiguous in the current standard.
This would disallow the ksh extensions (other than where they would be a
syntax error) everywhere, including fnmatch() and utilities doing
pattern matching, if I am reading it correctly. If so, the pax example
in the rationale I referenced, the one that shows or at least suggests
that ( needs to be escaped, could use updating too:
pax -r ... "*a\(\?"
to extract a filename ending with "a(?".
could be changed to
pax -r ... "*a\?"
to extract a filename ending with "a?".
or even
pax -r ... "*a(\?"
to extract a filename ending with "a(?".
to be explicit about the new requirement.
I think I see a small wording issue:
[...] If any character (ordinary, shell
special, or pattern special) is quoted, using either shell quoting
or (where shell quoting is not in effect) a <backslash> escape, that
pattern shall match the character itself. [...]
You excluded the bits in this proposal that would change the handling of
backslash, so the "(where shell quoting is not in effect)" doesn't look
right. It also seems more important to include "using either shell
quoting (where shell quoting is in effect) or [...]" to prevent someone
from interpreting this as applying to
find . -name '*.c'
Less important, under the current wording, backslash escapes the next
character, it does not quote it. The requirements of quoting and
escaping are the same, so perhaps it is okay to change the terminology.
Worth mentioning is that this change, and the recommendation to
implementations to not implement extensions to pattern matching other
than under non-standard options, contradicts the last comment on
<http://austingroupbugs.net/view.php?id=247>:
During May 27 2010 conf call, general consensus is that ksh93 filename generation appears to have many useful extensions, and we should move in that direction. See http://www2.research.att.com/sw/download/man/man1/ksh.html [^] for man page details. New wording invited.
Cheers,
Harald van Dijk
