{"thread":{"id":"59689","subject":"git grep -E doesn't accept \\b word boundaries?","startedAt":"2023-05-03T19:05:34Z","lastAt":"2023-05-03T20:45:24Z","messageCount":4,"participants":["Kevin Ushey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"476548","messageId":"CAJXgQP1j6JYbtikMuWGFn44+FVb3PfmuwiFrxDGLQAYgr92Wfw@mail.gmail.com","threadId":"59689","inReplyTo":null,"subject":"git grep -E doesn't accept \\b word boundaries?","fromName":"Kevin Ushey","fromEmail":"kevinushey@gmail.com","sentAt":"2023-05-03T19:04:47Z","receivedAt":"2023-05-03T19:05:34Z","isPatch":false,"sender":{"key":"kevinushey@gmail.com","avatar":null},"body":"Hello,\n\nI'm seeing the following, which I believe is unexpected. I have a file\nwith contents:\n\n$ cat hello.txt\nWholeWord\nWhole Word\nWhole\n\nI can use `git grep` to search with word boundaries; e.g.\n\n$ git grep --untracked '\\bWhole\\b'\nhello.txt:Whole Word\nhello.txt:Whole\n\nHowever, if I add `-E` to use extended regular expressions, the same\ninvocation finds no search results.\n\n$ git grep --untracked -E '\\bWhole\\b'\n\nThis does seem to work as expected with the '-w' flag, e.g.\n\n$ git grep --untracked -E -w 'Whole'\nhello.txt:Whole Word\nhello.txt:Whole\n\nas well as with POSIX word boundaries, e.g.\n\n$ git grep --untracked -E '[[:<:]]Whole[[:>:]]'\nhello.txt:Whole Word\nhello.txt:Whole\n\nIs this a bug, or am I misunderstanding some behavior in `git grep`?\nFor posterity:\n\n$ git grep --untracked -G '\\bWhole\\b'\nhello.txt:Whole Word\nhello.txt:Whole\n\n$ git grep --untracked -E '\\bWhole\\b'\n\n$ git grep --untracked -P '\\bWhole\\b'\nhello.txt:Whole Word\nhello.txt:Whole\n\nFor what it's worth, I don't see this issue with an older version of\n`git` on an Ubuntu 22.04 VM:\n\nroot@96722b73f316:~/test# git --version\ngit version 2.34.1\nroot@96722b73f316:~/test# git grep --untracked -E '\\bWhole\\b'\nhello.txt:Whole Word\nhello.txt:Whole\n\nThanks,\nKevin\n\n------\n\n[System Info]\ngit version:\ngit version 2.40.1\ncpu: arm64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Darwin 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28\nPST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64\ncompiler info: clang: 14.0.3 (clang-1403.0.22.14.1)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /opt/homebrew/bin/bash\n"},{"id":"476552","messageId":"xmqq1qjxqkbo.fsf@gitster.g","threadId":"59689","inReplyTo":"CAJXgQP1j6JYbtikMuWGFn44+FVb3PfmuwiFrxDGLQAYgr92Wfw@mail.gmail.com","subject":"Re: git grep -E doesn't accept \\b word boundaries?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-05-03T19:35:55Z","receivedAt":"2023-05-03T19:36:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Ushey <kevinushey@gmail.com> writes:\n\n> I'm seeing the following, which I believe is unexpected. I have a file\n> with contents:\n>\n> $ cat hello.txt\n> WholeWord\n> Whole Word\n> Whole\n>\n> I can use `git grep` to search with word boundaries; e.g.\n>\n> $ git grep --untracked '\\bWhole\\b'\n> hello.txt:Whole Word\n> hello.txt:Whole\n>\n> However, if I add `-E` to use extended regular expressions, the same\n> invocation finds no search results.\n>\n> $ git grep --untracked -E '\\bWhole\\b'\n\nDoes not seem to reproduce for me.  In a randomly picked repository\n(the source to git itself), I did\n\n    $ cat >hello.txt\n    WholeWord\n    Whole Word\n    Whole\n    ^D\n\nand \"git grep --untracked -E '\\bWhole\\b' hello.txt\" with or without\nthe \"-E\" option shows the same two lines as hits.\n\nWithout the pathspec hello.txt, the output includes one line from\nunpack-trees.c as well, but the hits from the untracked hello.txt\nare the same.\n\nThe tip of 'master', v2.40.0, v2.38.4, v2.37.4, v2.35.4 (they are by\nno means significant milestones---just some random versions I picked\nto test) all behave the same way.\n"},{"id":"476559","messageId":"CAJXgQP2Rvye6U64_Nv9a0VbTJF=WsT741J42gfQmP9vz74u0ww@mail.gmail.com","threadId":"59689","inReplyTo":"xmqq1qjxqkbo.fsf@gitster.g","subject":"Re: git grep -E doesn't accept \\b word boundaries?","fromName":"Kevin Ushey","fromEmail":"kevinushey@gmail.com","sentAt":"2023-05-03T20:32:15Z","receivedAt":"2023-05-03T20:32:56Z","isPatch":false,"sender":{"key":"kevinushey@gmail.com","avatar":null},"body":"Thanks for the quick response! I wonder if this issue could be macOS-specific?\n\nI just tried building git from sources, and I was able to reproduce\nthe issue with 2.39.3:\n\n$ ./git --version\ngit version 2.39.3\n$ ./git grep -E '\\bupdate\\b'\n\nBut everything works okay for me with 2.38.5:\n\n$ ./git --version\ngit version 2.38.5\nkevin@MBP-P2MQ:~/projects/git [(HEAD detached at v2.38.5)]\n$ ./git grep -E '\\bupdate\\b'\n.github/workflows/l10n.yml:          sudo apt-get update -q &&\n.gitignore:/git-update-index\n.gitignore:/git-update-ref\n< ... etc ...>\n\nI see this bit in the release notes, which seems potentially related:\n\nhttps://github.com/git/git/blob/69c786637d7a7fe3b2b8f7d989af095f5f49c3a8/Documentation/RelNotes/2.39.0.txt#L64-L65\n\nAnd indeed, I can't reproduce the issue if I compile git 2.39.3 with\n'make NO_REGEX=1'. So, perhaps a difference between git's compat regex\nlibrary and the one provided by macOS?\n\nThanks,\nKevin\n\nOn Wed, May 3, 2023 at 12:35 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Kevin Ushey <kevinushey@gmail.com> writes:\n>\n> > I'm seeing the following, which I believe is unexpected. I have a file\n> > with contents:\n> >\n> > $ cat hello.txt\n> > WholeWord\n> > Whole Word\n> > Whole\n> >\n> > I can use `git grep` to search with word boundaries; e.g.\n> >\n> > $ git grep --untracked '\\bWhole\\b'\n> > hello.txt:Whole Word\n> > hello.txt:Whole\n> >\n> > However, if I add `-E` to use extended regular expressions, the same\n> > invocation finds no search results.\n> >\n> > $ git grep --untracked -E '\\bWhole\\b'\n>\n> Does not seem to reproduce for me.  In a randomly picked repository\n> (the source to git itself), I did\n>\n>     $ cat >hello.txt\n>     WholeWord\n>     Whole Word\n>     Whole\n>     ^D\n>\n> and \"git grep --untracked -E '\\bWhole\\b' hello.txt\" with or without\n> the \"-E\" option shows the same two lines as hits.\n>\n> Without the pathspec hello.txt, the output includes one line from\n> unpack-trees.c as well, but the hits from the untracked hello.txt\n> are the same.\n>\n> The tip of 'master', v2.40.0, v2.38.4, v2.37.4, v2.35.4 (they are by\n> no means significant milestones---just some random versions I picked\n> to test) all behave the same way.\n"},{"id":"476561","messageId":"xmqqr0rxp2jl.fsf@gitster.g","threadId":"59689","inReplyTo":"CAJXgQP2Rvye6U64_Nv9a0VbTJF=WsT741J42gfQmP9vz74u0ww@mail.gmail.com","subject":"Re: git grep -E doesn't accept \\b word boundaries?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-05-03T20:45:18Z","receivedAt":"2023-05-03T20:45:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Ushey <kevinushey@gmail.com> writes:\n\n> Thanks for the quick response! I wonder if this issue could be macOS-specific?\n\nAh, yes, I somehow thought you mentioned Ubuntu and totally blocked\nthat macOS issue out of my mind, but I do recall that it has been\nreported that build with macOS native regexp library is broken a few\ntimes recently on this list.\n\n    https://lore.kernel.org/git/?q=macOS+regexp\n\nfinds this thread, which unfortunately was mistitled to make them\nsound as if they were about \"-P\", but the issue in the thread was\nabout extended regexp.\n\n  https://lore.kernel.org/git/03fd7ddb-8241-1a0a-3e82-d8083e4ce0f7@web.de/\n\n"}]}