lgrep and rgrep in Emacs - emacs

Question

I am having problems with the greps in Emacs.
a) grep doesnt seem to understand the .[ch] for searching .c and .h files. This is a default option provided by Emacs with the lgrep command. The example is searching for the word "global" in .c/.h files.
grep -i -nH "global" *.[ch]
grep: *.[ch]: No such file or directory
Grep exited abnormally with code 2 at Mon Feb 16 19:34:36
Is this format not valid?
b) Using rgrep I get the following error:
find . "(" -path "*/CVS" -o -path "*/.svn" -o -path "*/{arch}" -o -path "*/.hg" -o -path "*/_darcs" -o -path "*/.git" -o -path "*/.bzr" ")" -prune -o -type f "(" -iname "*.[ch]" ")" -print0 | xargs -0 -e grep -i -nH "global"
FIND: Wrong parameter format
Grep finished (matches found) at Mon Feb 16 19:37:10
I am using Emacs 22.3.1 on Windows XP with the GNU W32 Utils (grep, find, xargs etc.). Grep v2.5.3 and find v4.2.20.
What am I missing?
UPDATE:
Too bad one can't accept multiple answers...since the solution to my problems are spread out.
grep -i -nH "global" *.c *.h
This solves the first problem. Thanks luapyad!
(setq find-program "c:\\path\\to\\gnuw32\\find.exe")
emacs was indeed using the Windows find.exe. Forcing the gnu32 find fixed the second problem. Thanks scottfrazer.
However, I still like ack best.

Answer 1

I found out that using:
(setq find-program "\"C:/path/to/GnuWin32/bin/find.exe\"")
(setq grep-program "\"C:/path/to/GnuWin32/bin/grep.exe\"")
Works better in windows, since you could have a space laying around the path and will screw up eventually.
Notice I used the two programs in my .emacs file.
Hope it's of some help to some other programmer in need ;)

Answer 2

Well, there is always Ack and Ack.el

Answer 3

For a) it looks like there are simply no .c or .h files in the current directory.
For b) Windows is trying to use its own find instead of the one from the GNU W32 Utils. Try:
(setq find-program "c:\\path\\to\\gnuw32\\find.exe")

Answer 4

Adam Rosenfield comment is worth expanding into an answer:
grep -r --include=\*.[ch] --exclude=\*{CVS,.svn,arch} -i -nH
To make the example given in this question work, use this:
grep -i -nH --include=\*.[ch] "global" *
It is also helpful to set the variable grep-command providing defaults to M-x grep:
(setq grep-command "grep -i -nH --include=\*.[ch] ")
Also here are some other useful command line parameters to grep:
-n print the line number
-s suppress error messages
-r recursive

Answer 5

I think the general problem is the windows cmd "shell" behaves very differently to a unix shell in respect to filename expansion regexps and wildcards.
To answer your (a) above try using:
grep -i -nH "global" *.c *.h
(You will still get an "invalid argument" if no *.c's or *.h's exist).
Or you can use command line option --include=\*.[ch] to make windows grep do "proper" filename pattern matching (see grep --help for other options)

Answer 6

I usually just use M-x grep and alter the command line args when prompted if I need to. But I just tried running M-x lgrep and got the same thing as you. It simply means that no files match *.[ch] in the current directory. You can customize the default options to include -r and search recursively through child directories as well:
M-x customize-group RET grep RET
Search for lgrep in that buffer to find/edit the Grep Template.
As far as M-x rgrep goes, I suspect it has something to do with the Windows version of find not liking the default options. That command works fine for me on Linux. Search for rgrep in that same customize buffer and tweak those options until the Windows find is happy.
Sorry I can't be more help with the Windows options, but I'm not familiar with them.