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 files 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. 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/* 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 /bin/echo There's no need for / to have an entry for "bin". -- Stephane
