On Mon, Jun 1, 2026, 06:54 Andrei Borzenkov <[email protected]> wrote:
>
> On Sun, May 31, 2026 at 5:32 PM Andreas Schwab <[email protected]> wrote:
> >
> > On Mai 31 2026, Andrei Borzenkov wrote:
> >
> > > $ bar='\*'
> > > $ ls $bar
> > > ls: cannot access '\*': No such file or directory
> > > $
> > >
> > > Oops. Why it suddenly attempts to match *two* characters "\*" instead of
> > > just one literal "*"?
> >
> > Because '\*' is not a glob, so filename expansion is not performed.
> >
>
> Actually it is. Pathname expansion is performed on the result of the
> parameter expansion and pathname expansion interprets the current
> content of the word in question as pattern:
>
> After field splitting, if set -f is not in effect, each field in the
> resulting command line shall be expanded using the algorithm described
> in 2.14 Pattern Matching Notation, qualified by the rules in 2.14.3
> Patterns Used for Filename Expansion.
>
> bash decides to optimize globbing by skipping pathname expansion when
> it believes it is not necessary, but in this case it *is* necessary to
> arrive at the correct result.
>
> Now, if the file with the name "*" did not exist, the end result had
> been correct - bash returns the literal pattern string that includes
> '\'. But the result is wrong when the matching file actually exists.
You mention a number of combinations, so I'm not sure which pattern it
is you say has incorrect results depending on if a matching file exists
or not?
$ touch '*'; p='\*'; echo $p # 1A
\*
$ rm -f '*'; p='\*'; echo $p # 1B
\*
$ touch '*'; p='\**'; echo $p # 2A
*
$ rm -f '*'; p='\**'; echo $p # 2B
\**
