Re: help with pattern matching needed

[Christoph Anton Mitterer]

> Chet described it this way in August:
> 
>     It's tricky in the sense that quote removal, according to the
>     strict shell definition, is performed -- the literal quote
>     characters are removed and don't appear in the expanded pattern.
>     The complication is that the shell and pattern matcher have to
>     arrange for the quoted characters to be marked appropriately
>     for the pattern matcher itself, so quoted special characters
>     lose their special meaning and match themselves.
> 
> https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00187.html
> 
> Roughly speaking, shell-quoted characters are already treated as
> literals in the pattern.  There isn't the rigid separation you have
> to deal with when you're constructing a pattern for, say, grep(1).

Hmm that does explain some things...

But isn't this then a violation of POSIX? Or is there any part in it,
which indicates that behaviour, i.e. that already quoted strings are
already taken as literals with respect to the pattern?


> > Case 2:
> > *******
...
> It looks like \] is being treated as a literal ] in both cases.
> The difference seems to be in the parsing: dash gives up on the
> bracket expression, while bash consumes the rest of the script
> trying to close it.
> 
>     % cat ex1.sh
>     case $1 in
>         [.*^$[\]) printf '%s matched\n' "$1" ;;
>         *) printf "%s didn't match\\n" "$1" ;;
>     esac
>     % bash ex1.sh .
>     ex1.sh: line 2: unexpected EOF while looking for matching `]'
>     ex1.sh: line 5: syntax error: unexpected end of file
>     % dash ex1.sh .
>     . didn't match
>     % dash ex1.sh '[.xxxxxxxxxxxx^$[]'
>     [.xxxxxxxxxxxx^$[] matched

So if (d)ash behaves the same here (i.e. also taking already quoted
strings as literals with respect to the pattern).. then (d)as would
have a bug here in not failing on the missing closing ] ?

And even stranger that (d)ash then matches [.xxxxxxxxxxxx^$[] ... how
did you construct that?

Or is there any logic behind it? Perhaps, that since it doesn't finde a
closing ] (because that's taken literally, it also takes the first [
literally?



> > Case 3:
> > *******
...
> > I stumbled over the old $[] form of arithmetic expression, but I
> > guess
> > that cannot be it, cause then one would again have a missing
> > matching
> > ].
> 
> That is it, though.  The empty $[] substitutes "0" into the pattern.

So why doesn't it complain then about the (then) missing closing ] ?


>     % cat ex2.sh
>     case $1 in
>         [.*^$[]) printf '%s matched\n' "$1" ;;
>         *) printf "%s didn't match\\n" "$1" ;;
>     esac
>     % bash ex2.sh '[.xxxxxxx^0'
>     [.xxxxxxx^0 matched
> 
> However, as you noted, bash doesn't parse quite so greedily this
> time.  I don't know why not.

I see... unfortunate :-/


Thanks,
Chris.