Re: git bug: Perl compatible regular expressions do not work as expected

From: René Scharfe <l.s.r@web.de>
Date: Mar 28, 2023, 17:56 UTC
Message-ID: <4e03ea47-b0aa-d69e-6c54-fcbadb3b0641@web.de>
In-Reply-To: <xmqqsfdpj8ci.fsf@gitster.g>

Am 28.03.23 um 15:47 schrieb Junio C Hamano:

Show 15 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I suspect that 54463d32ef was done in a conservative way to avoid
>> unintended side effects to make ERE "enhanced".  I am not 100%
>> certain, but after reading the documentation you pointed at, I do
>> not see a valid expression without ENHANCED flag starting to mean
>> totally different thing with it (well, an extra '?' turning a
>> pattern from greedy to minimal may count as such a change in
>> semantics, but I do not see anybody sensible adding an extra '?'
>> in a pattern in the first place).
>
> Sorry, but that is nonsense.  We cannot avoid being backward
> incompatible if we suddenly flip the "enhanced" bit for BRE.  A
> sane pattern written expecting non-enhanced BRE can change its
> meaning when the "enhanced" mode is enabled.

Right, and there are even more enhancements for ERE, i.e. more incompatibilities. Not sure how big of a problem that actually would be, though.

> But if "enhanced" is what users want, and if that is what the other
> tools on the platform use, then perhaps flipping the "enhanced" bit
> may not be a bad idea.

Apple's grep(1) uses it, with and without -E:

https://github.com/apple-oss-distributions/text_cmds/search?q=REG_ENHANCED

E.g. awk(1) and sed(1) don't, AFAICS.

René