On 04/07/2019 09:09, Geoff Clare wrote:
Harald van Dijk <a...@gigawatt.nl> wrote, on 03 Jul 2019:
No, it's a context where shell-quoting backslash *doesn't* work. Therefore
the backslash should act as an escape character just like in find, pax,
fnmatch() and glob().
It's not about shell quoting the backslash, it's about whether shell quoting
can be used on the asterisk. The quoted sentence says that if shell quoting
cannot be used on the asterisk, then it can be escaped with a backslash
instead. But shell quoting can be used on the asterisk: just try
a='*'
ls -ld "$a"
This does work for listing only a file literally named '*'.
That's because of the double quotes around $a. Pathname expansion
is not done inside double quotes, so there is no pattern here, just
a string that contains a '*'.
Is that relevant? It still shows that shell quoting can force the '*' to
be treated literally, does it not?
In this case, whether pathname expansion is performed does not affect
the result. In the general case, words may be partly quoted, and the
quoted parts of such words are definitely supposed to be used in
pathname expansion, so let's go with a different example:
a='*'
ls -ld $a* #1
ls -ld "$a"* #2
Here, it is clear that pathname expansion is performed. #1 lists all
non-hidden files, #2 lists all files starting with '*'. Since shell
quoting works, under my understanding of your proposed wording, that
means backslash cannot be used to escape that '*', and
a='\*'
ls -ld $a*
must list all files starting with '\' since backslash does not function
as an escape character here.
It would be bizarre if the handling of '\' in $a is different from the
handling of '\' in $a*.
Cheers,
Harald van Dijk
