bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rupert Swarbrick
Subject: bug#19944: 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]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]