Re: BUG: git grep behave oddly with alternatives

From: René Scharfe <l.s.r@web.de>
Date: Jan 13, 2023, 17:24 UTC
Message-ID: <5f6908c8-3f84-92a3-b9d1-8689c500c1e9@web.de>
In-Reply-To: <230113.86ilhazved.gmgdl@evledraar.gmail.com>

Am 13.01.23 um 09:28 schrieb Ævar Arnfjörð Bjarmason:

Show 7 quoted lines

>
> There's a couple of ways out of this that I don't see in this thread:
>
> - Declare it not a problem: We have -G, -E and -P to map to BRE, ERE and
>   PCRE. One view is to say the first two must match POSIX, another is
>   tha whatever the platform thinks they should do is how they should
>   act.

I like that and it was my first reaction -- alternation is a non-standard extension to BREs. But we supported it explicitly since 3632cfc248 (Use compatibility regex library for OSX/Darwin, 2008-09-07), so not having it anymore is a regression that we should fix, I think.

Show 10 quoted lines

>   Of course that makes git regex invocations "unportable", but it might
>   be acceptable. People can always use PCRE if they want "portability".
>
> - Just mandate PCRE for Mac OS, then map -E to -P. We could do this with
>   the pcre2convert() API and PCRE2_CONVERT_POSIX_EXTENDED flag,
>   i.e. PCRE's own "translate this to ERE".
>
>   But Perl/PCRE syntax is already a superset of ERE syntax, minus things
>   like (*VERB), (?: etc., which people are unlikely to write without
>   intending to get the PCRE semantics.

PCRE2_CONVERT_POSIX_EXTENDED is a flag for pcre2_pattern_convert(), which allows converting an ERE into a PCRE2 regex (https://pcre.org/current/doc/html/pcre2convert.html). So this feature allows using PCRE for every kind of regexes, right?

There may be feature differences for EREs between libc on macOS, glibc and/or GAWK, but I'm not aware of any complaints so far. So I currently don't see the need for that.

René