Re: BUG: git grep behave oddly with alternatives

From: René Scharfe <l.s.r@web.de>
Date: Jan 13, 2023, 23:03 UTC
Message-ID: <e9913631-0534-ce47-ed73-2caff0f9d04a@web.de>
In-Reply-To: <5f6908c8-3f84-92a3-b9d1-8689c500c1e9@web.de>

Am 13.01.23 um 18:24 schrieb René Scharfe:

Show 18 quoted lines

> Am 13.01.23 um 09:28 schrieb Ævar Arnfjörð Bjarmason:
>>
>> - 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.

Thought that maybe this could help us matching NUL characters and fix the TODO in t7815, because PCRE2 can handle binary files just fine. But no: pcre2_pattern_convert() uses (NUL*) in its result, meaning that NUL is treated as a line separator and . (dot) won't match it. And it's still experimental according to the documentation link I mentioned above.

René