Just being picky, re:
"Arguments to find, pax, fnmatch() and glob() are others."
at the bottom, which to me should be:
"Arguments to exec('find',...), exec('pax',...), fnmatch() and glob() are
others."
as parameters of find and pax in scripts are shell words covered by the
statement preceding that. It is after parameter expansions and quote removal
that the resulting token value may be an argument string to be treated as a
pattern for those utilities.
On Wednesday, July 3, 2019 Geoff Clare <[email protected]> wrote:
Stephane Chazelas <[email protected]> wrote, on 03 Jul 2019:
>
> 2019-07-03 11:08:57 +0100, Geoff Clare:
> [...]
> > > And again, that's an incompatible change for dash, ksh88, ksh93,
> > > pdksh, mksh, bosh, yash where:
> > >
> > > a='\*'
> > > ls -ld $a
> > >
> > > lists the files that start with \
> >
> > Which is inconsistent with find, pax, fnmatch() and glob().
>
> And again, that argument doesn't hold.
>
> There's no find implementation that I know where
>
> find . -name '"*"*'
> find . -name '"$var"*'
>
> works the same as
>
> printf '%s\n' "*"*
> printf '%s\n' "$var"*
The goal is consistency of backslash handling. There was never any
intention in 1992 to require find, pax, fnmatch() and glob() to mimic
shell single quotes or double quotes, nor is there now, nor does there
need to be.
> fnamtch() didn't add \ support for consistency with the shell,
> It did add the *, ? and [ glob operators of the shell and the \
> quoting operator of the shell. \ is not a glob operator there
> but a quoting operator in its very limited syntax (compared to
> that of the shell which has other forms of quoting, and many
> forms of expansions).
>
> Adding it back to the shell *as an extra layer* hardly helps
> with consistency and adds confusion.
The proposed resolution makes clear that it is not an extra layer, it's
an alternative for situations where the shell quoting backslash is not
available. Thus providing consistency and reducing confusion.
> [...]
> > > a='\d*'
> > > ls -ld $a
> > >
> > > lists the filenames that start with \d
> >
> > Which is inconsistent with find, pax, fnmatch() and glob().
>
> Irrelevant, pax, fnmatch() and glob() don't do variable
> expansion. find -name '$a' is unspecified but in all
> implementations, that returns the files called $a literally.
The goal is consistency of how backslash behaves in patterns.
A direct pattern in a shell word and an indirect pattern in a shell
variable (that is then used unquoted) are two places a pattern can
occur. Arguments to find, pax, fnmatch() and glob() are others.
--
Geoff Clare <
[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
