On 22/06/2019 13:40, Stephane Chazelas wrote:
2019-06-22 09:07:40 +0100, Harald van Dijk:
[...]
In theory, pathname expansion is supposed to be done for every word, no
matter which characters it contains. Even in something as simple as
[...]
That's your way to look at it.
That's the way it's specified in POSIX.
Note that in:
ls -d /a/b/??/x/*
POSIX already implies that the globbing only applies to
components that have wildcards, that the shell doesn't need read
access to / nor /a to "generate" b, implying that that glob is
meant to succeed even if /a has no entry for "b" as long as /a/b
is searchable (and readable here to find the entries that match
??).
Right. This is covered by 2.13.3's
Specified patterns shall be matched against existing filenames and
pathnames, as appropriate. Each component that contains a pattern
character shall require read permission in the directory containing
that component. Any component, except the last, that does not contain
a pattern character shall require search permission. [...]
For components that do not include a "pattern character", this requires
using lstat() or such rather than readdir().
That's different for
ls -d /a/[b]/??/x/*
Where the shell needs read access to /a to find a file that
matches [b]. Those two globs are not guaranteed to find the same
files
Agreed.
ls -d /a/\b/??/x/*
like
ls -d /a/'b'/??/x/*
is guaranteed to find the same files as ls /a/b/??/x/*, because
that \ is just quoting, it's not a wildcard operator.
Agreed.
But in bash5's
files='/a/\b/??/x/*'
ls -d $files
That \ becomes a globbing operator, so we get the same list of
files as in a literal /a/[b]/??/x/*, not a literal /a/\b/??/x/*
That doesn't sound right. The backslash is removed per 2.13.1, and then
the path component is just "b". This does not contain a "pattern
character", so should not require search permission. I expect this to
match the same thing as /a/b/??/x/*, and both in my shell and in bash
that is what I see. Has this changed in one of the post-5.0 bash patches?
Cheers,
Harald van Dijk
