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


ls -d /a/\b/??/x/*
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.


But in bash5's

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?

Harald van Dijk

Reply via email to