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

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/* 

Another reason why that bash5 behaviour adds more confusion than
it helps.

IOW we already have two different behaviours in POSIX for when a
word (actually a path component) contains wildcard operators and
when it doesn't. Based on that:

echo foo

would not be asking the shell to list the currently directory
and search for an "echo" entry, just like in


There's no need for / to have an entry for "bin".


Reply via email to