All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: "Marco Nenciarini" <marco.nenciarini@enterprisedb.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: BUG: git grep behave oddly with alternatives
Date: Wed, 04 Jan 2023 15:13:29 +0900	[thread overview]
Message-ID: <xmqq8riivncm.fsf@gitster.g> (raw)
In-Reply-To: <343a891e-d737-0ace-26a9-3839d3bd5583@web.de> ("René Scharfe"'s message of "Tue, 3 Jan 2023 21:52:27 +0100")

René Scharfe <l.s.r@web.de> writes:

>    "For enhanced basic REs, ‘+’, ‘?’ and ‘|’ remain regular characters,
>     but ‘\+’, ‘\?’ and ‘\|’ have the same special meaning as the
>     unescaped characters do for extended REs, i.e., one or more
>     matches, zero or one matches and alteration, respectively."
>
> So apparently Apple chose a middle ground between basic and extended
> regular expressions for its grep and git grep.

Sounds like GNU extension to me.

> So GNU grep apparently made the same choice as Apple, probably far
> earlier.

Yup.

> Based on that I suggest:
> ...
>
> It would be simpler to use REG_ENHANCED everywhere it is defined instead
> of adding a Makefile setting, but it's a non-standard extension and
> might mean something else on other platforms.

OK.  Very conservative and good.

> Reported-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
>  Makefile         | 8 ++++++++
>  config.mak.uname | 1 +
>  grep.c           | 4 ++++
>  3 files changed, 13 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index db447d0738..15e7edc9d2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -289,6 +289,10 @@ include shared.mak
>  # Define NO_REGEX if your C library lacks regex support with REG_STARTEND
>  # feature.
>  #
> +# Define GIT_GREP_USES_REG_ENHANCED if your C library provides the flag
> +# REG_ENHANCED to enable enhanced basic regular expressions and you'd
> +# like to use it in git grep.
> +#
>  # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
>  # user.
>  #
> @@ -2037,6 +2041,10 @@ endif
>  ifdef NO_REGEX
>  	COMPAT_CFLAGS += -Icompat/regex
>  	COMPAT_OBJS += compat/regex/regex.o
> +else
> +ifdef GIT_GREP_USES_REG_ENHANCED
> +	COMPAT_CFLAGS += -DGIT_GREP_USES_REG_ENHANCED
> +endif
>  endif
>  ifdef NATIVE_CRLF
>  	BASIC_CFLAGS += -DNATIVE_CRLF
> diff --git a/config.mak.uname b/config.mak.uname
> index d63629fe80..14c145ae42 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -147,6 +147,7 @@ ifeq ($(uname_S),Darwin)
>  	FREAD_READS_DIRECTORIES = UnfortunatelyYes
>  	HAVE_NS_GET_EXECUTABLE_PATH = YesPlease
>  	CSPRNG_METHOD = arc4random
> +	GIT_GREP_USES_REG_ENHANCED = YesPlease
>
>  	# Workaround for `gettext` being keg-only and not even being linked via
>  	# `brew link --force gettext`, should be obsolete as of
> diff --git a/grep.c b/grep.c
> index 06eed69493..a8430daaba 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -502,6 +502,10 @@ static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
>  		regflags |= REG_ICASE;
>  	if (opt->pattern_type_option == GREP_PATTERN_TYPE_ERE)
>  		regflags |= REG_EXTENDED;
> +#if defined(GIT_GREP_USES_REG_ENHANCED) && defined(REG_ENHANCED)
> +	else
> +		regflags |= REG_ENHANCED;
> +#endif
>  	err = regcomp(&p->regexp, p->pattern, regflags);
>  	if (err) {
>  		char errbuf[1024];
> --
> 2.39.0

  reply	other threads:[~2023-01-04  6:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03  9:53 BUG: git grep behave oddly with alternatives Marco Nenciarini
2023-01-03 16:29 ` René Scharfe
2023-01-03 18:13   ` Marco Nenciarini
2023-01-03 20:52     ` René Scharfe
2023-01-04  6:13       ` Junio C Hamano [this message]
2023-01-04  7:46       ` Jeff King
2023-01-04 16:36         ` René Scharfe
2023-01-06  9:09           ` Jeff King
2023-01-08  0:42             ` René Scharfe
2023-01-08  1:27               ` Junio C Hamano
2023-01-11 18:56               ` Jeff King
2023-01-12 17:13                 ` René Scharfe
2023-01-12 17:52                   ` Ævar Arnfjörð Bjarmason
2023-01-12 21:54                   ` Jeff King
2023-01-13  8:28                     ` Ævar Arnfjörð Bjarmason
2023-01-13 17:19                       ` Junio C Hamano
2023-01-14  6:44                         ` René Scharfe
2023-01-14  8:31                           ` René Scharfe
2023-01-14 12:45                             ` Diomidis Spinellis
2023-01-14 16:08                               ` Junio C Hamano
2023-01-13 17:24                       ` René Scharfe
2023-01-13 23:03                         ` René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq8riivncm.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=marco.nenciarini@enterprisedb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.