git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git grep -E doesn't accept \b word boundaries?

From
KUKevin Ushey <kevinushey@gmail.com>
Date
May 3, 2023, 20:32 UTC
Message-ID
<CAJXgQP2Rvye6U64_Nv9a0VbTJF=WsT741J42gfQmP9vz74u0ww@mail.gmail.com>
In-Reply-To
<xmqq1qjxqkbo.fsf@gitster.g>
Thanks for the quick response! I wonder if this issue could be macOS-specific?

I just tried building git from sources, and I was able to reproduce the issue with 2.39.3:

$ ./git --version git version 2.39.3 $ ./git grep -E '\bupdate\b'

But everything works okay for me with 2.38.5:

$ ./git --version git version 2.38.5 kevin@MBP-P2MQ:~/projects/git [(HEAD detached at v2.38.5)] $ ./git grep -E '\bupdate\b' .github/workflows/l10n.yml: sudo apt-get update -q && .gitignore:/git-update-index .gitignore:/git-update-ref < ... etc ...>

I see this bit in the release notes, which seems potentially related:
https://github.com/git/git/blob/69c786637d7a7fe3b2b8f7d989af095f5f49c3a8/Documentation/RelNotes/2.39.0.txt#L64-L65

And indeed, I can't reproduce the issue if I compile git 2.39.3 with 'make NO_REGEX=1'. So, perhaps a difference between git's compat regex library and the one provided by macOS?

Thanks, Kevin

On Wed, May 3, 2023 at 12:35 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 41 quoted lines
>
> Kevin Ushey <kevinushey@gmail.com> writes:
>
> > I'm seeing the following, which I believe is unexpected. I have a file
> > with contents:
> >
> > $ cat hello.txt
> > WholeWord
> > Whole Word
> > Whole
> >
> > I can use `git grep` to search with word boundaries; e.g.
> >
> > $ git grep --untracked '\bWhole\b'
> > hello.txt:Whole Word
> > hello.txt:Whole
> >
> > However, if I add `-E` to use extended regular expressions, the same
> > invocation finds no search results.
> >
> > $ git grep --untracked -E '\bWhole\b'
>
> Does not seem to reproduce for me.  In a randomly picked repository
> (the source to git itself), I did
>
>     $ cat >hello.txt
>     WholeWord
>     Whole Word
>     Whole
>     ^D
>
> and "git grep --untracked -E '\bWhole\b' hello.txt" with or without
> the "-E" option shows the same two lines as hits.
>
> Without the pathspec hello.txt, the output includes one line from
> unpack-trees.c as well, but the hits from the untracked hello.txt
> are the same.
>
> The tip of 'master', v2.40.0, v2.38.4, v2.37.4, v2.35.4 (they are by
> no means significant milestones---just some random versions I picked
> to test) all behave the same way.
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 4 in “git grep -E doesn't accept \b word boundaries?”
  1. Kevin UsheyMay 3, 2023
  2. Junio C HamanoMay 3, 2023
  3. Kevin UsheyMay 3, 2023
  4. Junio C HamanoMay 3, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.