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 René
