Re: [9front] sed: fix moving '^' match

[tlaronde@polynum.com]

On Sun, Aug 27, 2023 at 10:33:50AM +0200, hiro wrote:
> 
> we must be disagreeing about some fundamental understanding instead.
> it's hard for me to see still where *exactly* we differ.
> 
> just to make sure. you are aware of the other basic symmetrically
> asymmetric problems that one encounters in everyday life with sed,
> right? the asymmetry between input and output...
> 
> 
> cpu% echo aa | sed 's/aa/a/g'
> a
> cpu% echo aaaa | sed 's/aa/a/g'
> aa

Isn't this exactly a counter-example to your interpretation of the
behavior of '^aa' with "sliding" beginning (^ anchor) of the line?

To be consistent with what you interpret, "echo aaaa | sed 's/aa/a/g'"
should yield: "a"; and, in fact, all strings of more than one "a" should
give "a", since the "new" string, retaken from its new beginning, should
be reparsed.

I think the implicit understanding of 's/^..//g' is that once the first
two characters are discarded, the scanning has advanced in the original
string and hence it is not anymore at the beginning.

Ori example of the lack of symetry of behavior with 's/aa$//g' is to the
point too.

In some sense, this interpretation of 'g' is considering that 'g' makes an
infinite looping of the regex, applied to the resulting string and that should
only end if no modification is made. Seems incorrect to me.

The current behavior may be bug compatible with V8. It remains a bug
IMHO.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C