Re: Pattern bug on (a*|)~^(*b)

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2023-07-27 18:02:30 -0700, Bart Schaefer:
> On Tue, Jul 25, 2023 at 11:47 AM Johan Grande <nahoj@xxxxxxxxx> wrote:
> >
> > I don't get it. What are the different patterns tried during this
> > left-to-right evaluation of (|a*)~^(*b) ?
> 
> I'm going to invoke my "PWS may be able to explain some more" remark,
> but basically once you cross the "~" it's no longer possible to
> backtrack again; so it tries to match the empty alternative, gets an
> empty result set, excludes ^(*b) from that result set leaving a
> still-empty set, can't go back, and fails because the final result is
> empty.  I don't recall all the details but this has something to do
> with X~Y implemented as "exclude Y from the result of X".

I have to say I'm with the OP and don't understand that
explanation either.

It also doesn't seem to tie in with the fact that in globbing
the part after ~ is seemingly done *after* globbing so with
very low precedence, as in ./**/*.txt~*/src/* finding all the
txt files including in src dirs, but the */src/* filtered out
afterwards.

Even if that's "how it works", I struggle to see how it can be
seen as anything but a bug. It's not working as documented, and
I can't really see how we would document it.

See also:

$ [[ ab = a(|a*)~^*b ]]; echo $?
1
$ [[ ab = a(|*b)~^*b ]]; echo $?
1
$ [[ ab = a(*z|*b)~^*b ]]; echo $?
0

Which doesn't seem to tie in with the explanation.

-- 
Stephane