From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17496 invoked from network); 27 Aug 2023 09:59:34 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 27 Aug 2023 09:59:34 -0000 Received: from smtp.smtpout.orange.fr ([80.12.242.53]) by 9front; Sun Aug 27 05:54:32 -0400 2023 Received: from cauchy.polynum.local ([92.184.112.210]) by smtp.orange.fr with ESMTPSA id aCTUqDWj8VBAGaCTUqaaYO; Sun, 27 Aug 2023 11:54:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1693130069; bh=UY2PkFtOBrhMInqTP1qFaxS3cTCPGNMeGapqB6/v1f8=; h=Date:From:To:Subject:References:In-Reply-To; b=tlQ4oNZtV4OAYdys6IE+pYPXawngL4pBpjDz2pXRdnCBVb+xupa9UWRcjvdEYtJAi cYpFOQz2dBeCwi404M2Tp0tdbaYffXVYByaSH62Ki8pd3KNRatkFRvn216MGr/2tvw YStzSpH4uI3E0qGO6klUMXFanujdfXj9hoa+j19Qqbz47F6U+J9UbQ6I2nM7pY07A9 HnEysKWjDkiIvo1iz9rF4EcsOLr0pe4hCFUpieuVo/UbioFRjJUprEwsTjxTiqP0dW PctkyOQ+UmZPGfgxda62ZS+LmacVvcFhmkpFp1EsvElZcJ00yIBBa91rlfPZj1DLYh AMIRjYZP9uPTA== X-ME-Helo: cauchy.polynum.local X-ME-Auth: bGFyb25kZS50aGllcnJ5QG9yYW5nZS5mcg== X-ME-Date: Sun, 27 Aug 2023 11:54:29 +0200 X-ME-IP: 92.184.112.210 Received: from cauchy.polynum.local (localhost [127.0.0.1]) by cauchy.polynum.local (8.15.2/8.15.2) with ESMTP id 37R9sRJu001975 for <9front@9front.org>; Sun, 27 Aug 2023 11:54:27 +0200 (CEST) Received: (from tlaronde@localhost) by cauchy.polynum.local (8.15.2/8.14.9/Submit) id 37R9sQpI002026 for 9front@9front.org; Sun, 27 Aug 2023 11:54:26 +0200 (CEST) X-Authentication-Warning: cauchy.polynum.local: tlaronde set sender to laronde.thierry@orange.fr using -f Date: Sun, 27 Aug 2023 11:54:26 +0200 From: tlaronde@polynum.com To: 9front@9front.org Message-ID: References: <26E0B9AD31488853D40C701E19370A2D@eigenstate.org> <2NS6A93Q4VONO.2LMPXO8M4I4GW@wilsonb.com> <3OWTA7C36ZVYA.3C6IMNK32OWEU@wilsonb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible wrapper-based CSS module core generator Subject: Re: [9front] sed: fix moving '^' match Reply-To: 9front@9front.org Precedence: bulk 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 http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C