grep.el bug?

grep.el bug?

[David Abrahams]

I just rebuilt emacs from CVS.  On line 541 of grep.el, a change was
made about a year ago that seems to be breaking grep-find for me.

    (let ((null-device nil))		; see grep
      (grep command-args))))

This always leads to the following backtrace for me:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  call-process("find" nil nil nil nil "-print0")
  grep-compute-defaults()
  grep-process-setup()
  compilation-start("find . -type f -not -path \"*/CVS/*\" ...)
  grep("find . -type f -not -path \"*/CVS/*\" -not -name \ ...)
  grep-find("find . -type f -not -path \"*/CVS/*\" -not    ...)
  call-interactively(grep-find)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

As far as I can tell, null-device gets passed as the 5th argument to
call-process, which expects only strings after its 4th argument.  But
this can't have remained broken for everyone for a whole year, can it?
So I must be missing something.  The comment that directs me to "see
grep" leaves me completely in the dark.

Clues, anyone?

Thanks in advance,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Re: grep.el bug?

[David Abrahams]

David Abrahams wrote:
> I just rebuilt emacs from CVS.  On line 541 of grep.el, a change was
> made about a year ago that seems to be breaking grep-find for me.
> 
>     (let ((null-device nil))		; see grep
>       (grep command-args))))
> 
> This always leads to the following backtrace for me:
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   call-process("find" nil nil nil nil "-print0")
>   grep-compute-defaults()
>   grep-process-setup()
>   compilation-start("find . -type f -not -path \"*/CVS/*\" ...)
>   grep("find . -type f -not -path \"*/CVS/*\" -not -name \ ...)
>   grep-find("find . -type f -not -path \"*/CVS/*\" -not    ...)
>   call-interactively(grep-find)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)
> 
> As far as I can tell, null-device gets passed as the 5th argument to
> call-process, which expects only strings after its 4th argument.  But
> this can't have remained broken for everyone for a whole year, can it?
> So I must be missing something.  The comment that directs me to "see
> grep" leaves me completely in the dark.
> 
> Clues, anyone?

Here's one clue: I have customized grep-find-command.  I believe that if
I hadn't,

     (unless grep-find-command
       (grep-compute-defaults))

would cause grep-compute-defaults to be called early enough to make the
nil-ness of null-device irrellevant.  Hah, yes, that is in fact the case.

The grep function has a slightly more sophisticated check:


     (unless (and grep-command
		  (or (not grep-use-null-device) (eq grep-use-null-device t)))

I don't know exactly what the right fix is, but it seems to me these
tests ought to be encapsulated, or just incorporated into
grep-compute-defaults.  Hmm, something like that seems to be there
already. Since I don't know what the original authors of this code were
thinking, I'm having trouble thinking of a change that preserves what's
currently working but doesn't just make more of a mess.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Re: grep.el bug?

[Richard Stallman]

    The grep function has a slightly more sophisticated check:


	 (unless (and grep-command
		      (or (not grep-use-null-device) (eq grep-use-null-device t)))

Putting that into grep-find seems like a simple solution.
I will do that.  Thanks: