Am 14.01.23 um 07:44 schrieb René Scharfe: > Am 13.01.23 um 18:19 schrieb Junio C Hamano: >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >>> On Thu, Jan 12 2023, Jeff King wrote: >>> >>>> So it does seem like all bets are off for what people can and should >>>> expect here. Which isn't to say we should make things worse. I mostly >>>> wondered if REG_ENHANCED might take us closer to what glibc was doing by >>>> default, but it doesn't seem like it. >> >> I thought that René's "Use enhanced only when doing BRE" was fairly >> focused, but I am very tempted to accept ... >> >>> 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. >> >> ... this view. The story "BRE and ERE work via what system >> libraries provide, and 'git grep' matches what system grep' does" is >> an easy to understand view. > > That was my stance in my first reply as well. But 3632cfc248 (Use > compatibility regex library for OSX/Darwin, 2008-09-07) explicitly > added alternation support for BREs on macOS, and 1819ad327b (grep: fix > multibyte regex handling under macOS, 2022-08-26) removed it seemingly > by accident. And grep(1) does support them on macOS 13.1: > > $ uname -rs > Darwin 22.2.0 > $ which grep > /usr/bin/grep > $ grep --version > grep (BSD grep, GNU compatible) 2.6.0-FreeBSD > $ grep '\(REG_STARTEND\|NeededForASAN\)' Makefile > # Define NO_REGEX if your C library lacks regex support with REG_STARTEND > NO_REGEX = NeededForASAN And I neglected to copy the author of 1819ad327b until now. :-| @Diomidis: Here's a link to the start of this thread: https://lore.kernel.org/git/f82ae28a-fb56-8d1f-96c8-550b61439d3a@xxxxxxxxxxxxxxxx/ René
