emacs rgrep fails in find command (Windows 7)

Question

This seems like a dumb question and maybe it should be directed to a forum for gnuwin32, but I'll give it a try here.

I'm using grep from within emacs for Windows. I've had to use grep-find vs rgrep, which I would prefer to use because it weeds out many files I don't want to grep. Unfortunately, rgrep seems to create a 'find' command that is so long that it chokes and gives an error.

Using M-x rgrep to search for 'import' in my python files (silly example, I know) gives this output:

find . -type d "(" -path "/SCCS" -o -path "/RCS" -o -path "/CVS" -o -path "/MCVS" -o -path "/.svn" -o -path "/.git" -o -path "/.hg" -o -path "/.bzr" -o -path "*/_MTN" -o -path "*/_darcs" -o -path "/{arch}" ")" -prune -o "(" -name ".#" -o -name ".o" -o -name "~" -o -name ".bin" -o -name ".bak" -o -name ".obj" -o -name ".map" -o -name ".ico" -o -name ".pif" -o -name ".lnk" -o -name ".a" -o -name ".ln" -o -name ".blg" -o -name ".bbl" -o -name ".dll" -o -name ".drv" -o -name ".vxd" -o -name ".386" -o -name ".elc" -o -name ".lof" -o -name ".glo" -o -name ".idx" -o -name ".lot" -o -name ".fmt" -o -name ".tfm" -o -name ".class" -o -name ".fas" -o -name ".lib" -o -name ".mem" -o -name ".x86f" -o -name ".sparcf" -o -name ".dfsl" -o -name ".pfsl" -o -name ".d64fsl" -o -name ".p64fsl" -o -name ".lx64fsl" -o -name ".lx32fsl" -o -name ".dx64fsl" -o -name ".dx32fsl" -o -name ".fx64fsl" -o -name ".fx32fsl" -o -name ".sx64fsl" -o -name ".sx32fsl" -o -name ".wx64fsl" -o -name ".wx32fsl" -o -name ".fasl" -o -name ".ufsl" -o -name ".fsl" -o -name ".dxl" -o -name ".lo" -o -name ".la" -o -name ".gmo" -o -name ".mo" -o -name ".toc" -o -name ".aux" -o -name ".cp" -o -name ".fn" -o -name ".ky" -o -name ".pg" -o -name ".tp" -o -name ".vr" -o -name ".cps" -o -name ".fns" -o -name ".kys" -o -name ".pgs" -o -name ".tps" -o -name ".vrs" -o -name ".pyc" -o -name ".pyo" ")" -prune -o -type f "(" -iname "*.py" ")" -exec grep -i -nH -e "import" {} + find: paths must precede expression Usage: find [-H] [-L] [-P] [path...] [expression]

If I cut and paste this command into a cygwin window, which pulls find from /usr/bin, it works just fine and finds several instances. If I paste the same command into a cmd window which then uses gnuwin32/bin/find.exe, I get the same error as above (find: paths must precede expression). I also tried the command in a mingw shell and it works there (using /msys/1.0/bin/find.exe). To complicate matters, copying the mingw version of find into /gnuwin32/bin/ didn't help. No errors, but the grep never actually finds anything. Worse, doing that breaks 'grep-find' in the same way; nothing gets found.

I'm guessing there's a limit to the length of the overall command that I'm hitting here when using the gnuwin32 version of 'find'.

I think I could just give up on gnuwin32 and change my path to point to /msys/1.0/bin for commands that I use, but those commands wouldn't run in a cmd window any longer, at least not without having access to mingw DLLs. Part of me wants to know why the gnuwin32 version of find is choking. Any ideas? Sorry for the long-winded question.

Answer 1

Does emacs know where are the executables?

I have something like this in my .emacs you may want adopt as per your file paths

 ;;; excutable paths (for unix commands from MSYS and git from msysgit)
 (setq exec-path (append exec-path
                         '("C:/MinGW/msys/1.0/bin/"
                           "C:/MinGW/bin/"
                           "c:/MinGW/mingw32/bin"

                           "C:/Program Files (x86)/Git/bin")))

Answer 2

For me, the correct answer to this problem was found here:

Gnuwin32 find.exe expands wildcard before performing search

I downloaded unxutils.zip listed in the above answer and extracted the find.exe from there to my emacs bin folder. I don't recommend copying to emacs bin folder as a best practice but it avoids a lot of configuration overhead and it gets you up and running instantly.