GNU bug report logs - #19944
25.0.50; vc-git-grep doesn't use grep-read-files correctly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19944 in the body.
You can then email your comments to 19944 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rupert Swarbrick <ruperts <at> broadcom.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 25.0.50; vc-git-grep doesn't use grep-read-files correctly
Date: Wed, 25 Feb 2015 11:39:23 +0000

The vc-git-grep function uses grep-read-files to figure out the list of
files to check. This gets glued to the end of the git grep command
line. With the default value of grep-files-aliases, if the user enters
"all" for their files, grep-read-files returns the string "* .*".

If you do the following:

   cd /path/to/my/git/repo
   git grep foo -- * .*

then you get something like:

  /path/to/my/git/repo> git grep foo -- * .*
  fatal: ..: '..' is outside repository

because .* expands to a list including "..".

Now, the code in vc-git-grep constructs a string that looks basically
like the above. If you run vc-git-grep in the top-level directory of a
git repository and select "all" for file type then it errors out because
of this problem.


I did wonder whether this was a bug in grep.el, but it isn't:
grep-read-files seems to be used only in "grep" and "lgrep", which
construct commands like

   grep -nH foo * .*

Since the grep invocation is non-recursive, this isn't a problem. If you
run rgrep, it generates something more like

  find -name <blah blah> | grep <blah blah>

and doesn't seem to use grep-read-files at all.


We're also doing the wrong thing when the user gives a pattern. For
example, if I go into the top-level Emacs directory and run

  M-x vc-git-grep

enter vc-git-grep as the string to search for and enter *g* for the
files to search, then I get:

  Grep started at Wed Feb 25 11:17:28

  git --no-pager grep -n -e vc-git-grep -- *g*

  Grep finished with no matches found at Wed Feb 25 11:17:28

If I type '*g*' instead, I get:

  git --no-pager grep -n -e vc-git-grep -- '*g*'
  lisp/ChangeLog:16437:	* vc/vc-git.el (vc-git-grep): Disable pager.
  lisp/ChangeLog.14:16592:	(vc-git-extra-menu, vc-git-extra-status-menu, vc-git-grep):
  lisp/ChangeLog.16:18483:	* vc/vc-git.el (vc-git-grep): Remove --no-color.  (Bug#9408)
  lisp/ChangeLog.16:18484:	(vc-git-grep): Prepend "PAGER=" to `compilation-environment'
  lisp/ChangeLog.16:18662:	* vc/vc-git.el (vc-git-grep): Use --no-color.  (Bug#9408)
  lisp/vc/vc-git.el:1124:      '(menu-item "Git grep..." vc-git-grep
  lisp/vc/vc-git.el:1152:(defun vc-git-grep (regexp &optional files dir)

  Grep finished (matches found) at Wed Feb 25 11:18:17

(The strange looking pattern is so that there would be a match for the
 shell glob in the top level directory to make sure it got expanded: if
 I'd typed *.el, things would have worked as expected because there are
 no elisp files in the top-level Emacs directory)

One possible fix is to write a vc-git-grep-read-files function that
behaves very similarly to grep-read-files, but overrides some of the
mapping with a vc-git-grep-files-aliases variable. That should be an
alist that contains at least '("all" . "") by default.

If it successfully looked up something in the dictionary, the function
would then split on spaces and then shell quote each resulting word. If
the result isn't from a dictionary lookup, an easy approach is to do the
same thing: split on spaces and then quote. This lets the user enter
something like *.c *.h and have the right thing happen. It doesn't allow
the user to enter 'with a space.*' but maybe we don't care.


Rupert



In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2015-02-09 on lc-cam-077
Repository revision: 2f7008715326a49770fcb82003ed78eab28c0626
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Red Hat Enterprise Linux Server release 6.4 (Santiago)

Configured using:
 `configure
 --prefix=/snipped/
 --with-xml2 --without-sound --without-rsvg --without-imagemagick
 --with-x-toolkit=lucid'

Configured features:
XPM JPEG TIFF GIF PNG GPM DBUS GCONF NOTIFY ACL LIBSELINUX GNUTLS
LIBXML2 FREETYPE XFT ZLIB

[Rest snipped: it's not relevant to this bug report]

Message #8 received at 19944 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Rupert Swarbrick <ruperts <at> broadcom.com>
Cc: 19944 <at> debbugs.gnu.org
Subject: Re: bug#19944: 25.0.50; vc-git-grep doesn't use grep-read-files
 correctly
Date: Thu, 03 Dec 2020 12:50:14 +0100

Rupert Swarbrick <ruperts <at> broadcom.com> writes:

> The vc-git-grep function uses grep-read-files to figure out the list of
> files to check. This gets glued to the end of the git grep command
> line. With the default value of grep-files-aliases, if the user enters
> "all" for their files, grep-read-files returns the string "* .*".
>
> If you do the following:
>
>    cd /path/to/my/git/repo
>    git grep foo -- * .*
>
> then you get something like:
>
>   /path/to/my/git/repo> git grep foo -- * .*
>   fatal: ..: '..' is outside repository
>
> because .* expands to a list including "..".

(This bug report unfortunately got no response at the time.)

Looks like this has been fixed in more recent versions of Emacs.  Trying
this, I get:

git --no-pager grep -n --color -i -e emacs -- \* .\[\!.\]\* ..\?\*

and everything works are it should, I think.

> We're also doing the wrong thing when the user gives a pattern. For
> example, if I go into the top-level Emacs directory and run
>
>   M-x vc-git-grep
>
> enter vc-git-grep as the string to search for and enter *g* for the
> files to search, then I get:
>
>   Grep started at Wed Feb 25 11:17:28
>
>   git --no-pager grep -n -e vc-git-grep -- *g*

This, too -- I get:

git --no-pager grep -n --color -i -e emacs -- \*g\*

So I'm guessing this has been fixed, and I'm closing this bug report.
If there's still a problem here, please respond to the debbugs address,
and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.