Re: help with pattern matching needed

[Chet Ramey]

On 1/7/22 5:15 PM, Christoph Anton Mitterer wrote:
> > 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?

It's not a violation. There are a couple of interpretations that attempt to
clarify the distinction between "shell-quoted characters" and characters
that are  quoted for the pattern. These primarily involve backslashes,
since the only way to quote a pattern special character in a pattern is by
using a backslash, but it applies to other shell quoting as well.

For instance, if you have

case . in
'[.]')  echo match ;;
*)      echo no match ;;
esac

do you think the user's desire is to have it print `match'?


> > > 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 ] ?

There's no missing closing bracket. dash doesn't understand $[], and an
opening bracket without a matching close is not a pattern syntax error,
just a string to match.

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

Why is this strange? That's a valid pattern expression for dash's matcher
(the backslash escapes the ending `]'). The `*' in the pattern matches an
arbitrary number of `x's.


> > > 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 ] ?

Because there is no `missing' closing bracket. A valid bracket expression
requires unquoted open and close brackets. If a string doesn't have those,
it's just a sequence of characters to match, as we see here:

> >      % 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 :-/

I answered this in a different message.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/