# git grep -E doesn't accept \b word boundaries? 4 messages from 2023-05-03 to 2023-05-03. Participants: Kevin Ushey, Junio C Hamano. Thread: https://gitlist.dev/t/59689 ## Kevin Ushey, 2023-05-03 19:04 Subject: git grep -E doesn't accept \b word boundaries? Message-ID: URL: https://gitlist.dev/e/CAJXgQP1j6JYbtikMuWGFn44%2BFVb3PfmuwiFrxDGLQAYgr92Wfw%40mail.gmail.com ``` Hello, 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' This does seem to work as expected with the '-w' flag, e.g. $ git grep --untracked -E -w 'Whole' hello.txt:Whole Word hello.txt:Whole as well as with POSIX word boundaries, e.g. $ git grep --untracked -E '[[:<:]]Whole[[:>:]]' hello.txt:Whole Word hello.txt:Whole Is this a bug, or am I misunderstanding some behavior in `git grep`? For posterity: $ git grep --untracked -G '\bWhole\b' hello.txt:Whole Word hello.txt:Whole $ git grep --untracked -E '\bWhole\b' $ git grep --untracked -P '\bWhole\b' hello.txt:Whole Word hello.txt:Whole For what it's worth, I don't see this issue with an older version of `git` on an Ubuntu 22.04 VM: root@96722b73f316:~/test# git --version git version 2.34.1 root@96722b73f316:~/test# git grep --untracked -E '\bWhole\b' hello.txt:Whole Word hello.txt:Whole Thanks, Kevin ------ [System Info] git version: git version 2.40.1 cpu: arm64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Darwin 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64 compiler info: clang: 14.0.3 (clang-1403.0.22.14.1) libc info: no libc information available $SHELL (typically, interactive shell): /opt/homebrew/bin/bash ``` ## Junio C Hamano, 2023-05-03 19:35 Subject: Re: git grep -E doesn't accept \b word boundaries? Message-ID: URL: https://gitlist.dev/e/xmqq1qjxqkbo.fsf%40gitster.g In-Reply-To: ``` Kevin Ushey 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. ``` ## Kevin Ushey, 2023-05-03 20:32 Subject: Re: git grep -E doesn't accept \b word boundaries? Message-ID: URL: https://gitlist.dev/e/CAJXgQP2Rvye6U64_Nv9a0VbTJF%3DWsT741J42gfQmP9vz74u0ww%40mail.gmail.com In-Reply-To: ``` 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 wrote: > > Kevin Ushey 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. ``` ## Junio C Hamano, 2023-05-03 20:45 Subject: Re: git grep -E doesn't accept \b word boundaries? Message-ID: URL: https://gitlist.dev/e/xmqqr0rxp2jl.fsf%40gitster.g In-Reply-To: ``` Kevin Ushey writes: > Thanks for the quick response! I wonder if this issue could be macOS-specific? Ah, yes, I somehow thought you mentioned Ubuntu and totally blocked that macOS issue out of my mind, but I do recall that it has been reported that build with macOS native regexp library is broken a few times recently on this list. https://lore.kernel.org/git/?q=macOS+regexp finds this thread, which unfortunately was mistitled to make them sound as if they were about "-P", but the issue in the thread was about extended regexp. https://lore.kernel.org/git/03fd7ddb-8241-1a0a-3e82-d8083e4ce0f7@web.de/ ```