On 24/09/2019 12:24, Geoff Clare wrote:
Harald van Dijk <a...@gigawatt.nl> wrote, on 24 Sep 2019:
2. Existing practice in most shells that do treat backslash as special in
"indirect" patterns in pathname expansions is only to match patterns
against existing pathnames if the pattern includes a '*', '?' or '[' that
is treated as special. This prevents accidental removal of backslash
I cannot find any shell that behaves this way in its current version. Can
you share some details about what shells you tested?
Bash 4 on Linux and bash 3 on macOS (I recall someone saying that bash 2
also behaved the same way).
There is a reason I wrote "in its current version". I do not think it is
reasonable to describe bash 4 behaviour that had already been changed
when this was being discussed as "existing practice".
Regardless, a single shell is not enough to say "most shells", not even
if it is multiple versions of that single shell.
I think the way the bug 1234 resolution specifies it (as per bash2/3/4) is
more straightforward and easier for users to understand. It's a simple binary
choice: either matching against existing pathnames is performed or it isn't.
If it is performed, all special pattern-matching characters, including
backslash, have their special meaning in all components of the pattern.
You get situations where $dir/file1 and $dir/file2 name two files, but
$dir/file[12] cannot be used to match them both in a single word,
though. That is a problem that NetBSD sh does not have, and one that the
alternatives of always treating indirect \ as literal or never doing so
also do not have.
Cheers,
Harald van Dijk
