all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Weird grep.el behavior
@ 2010-04-08  2:35 Christoph
  0 siblings, 0 replies; only message in thread
From: Christoph @ 2010-04-08  2:35 UTC (permalink / raw)
  To: emacs-devel

Some things in grep.el that have been bugging me for a while.

See the following code

     (dolist (setting '(grep-command grep-template
                grep-use-null-device grep-find-command
                grep-find-template grep-find-use-xargs
                grep-highlight-matches))
       (set setting
        (or (cadr (assq setting host-defaults))
            (cadr (assq setting defaults)))))

There is a problem in the or statement, but only with the option 
grep-use-null-device. Using M-x grep for the fist time host-defaults are 
nil, so grep-use-null-device is set to default, which is autodetect. 
This causes the null-device test to be executed and (in my case) the 
result is nil, i.e. grep-use-null-device is set to nil. Now, the next 
time I execute M-x grep, the above code is supposed to detect that the 
host-defaults have been set the last time and use those. However, when 
it gets to grep-use-null-device the first cadr returns the value of 
grep-use-null-device, which is nil, and the or executes the second 
branch, assigning the autodetect to grep-use-null-device. All other 
options keep their host-default value. I assume this this is not correct.

The following patch will fix this:

=== modified file 'lisp/progmodes/grep.el'
--- lisp/progmodes/grep.el      2010-01-31 21:47:47 +0000
+++ lisp/progmodes/grep.el      2010-04-08 00:11:28 +0000
@@ -513,8 +513,8 @@
                        grep-find-template grep-find-use-xargs
                        grep-highlight-matches))
        (set setting
-          (or (cadr (assq setting host-defaults))
-              (cadr (assq setting defaults)))))
+          (cadr (or (assq setting host-defaults)
+                     (assq setting defaults)))))

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

Only if assq returns nil, i.e. the host-defaults have never been set, 
the function assigns the defaults. Otherwise it uses the host-defaults.

The above described leads to some funny behavior which I can't really 
explain.

I have two Windows XP machines, which, when I execute M-x grep for the 
first time, present the following options: grep -nH. Running grep works 
fine the first time. Second time I run grep, I get an error code 2 and 
an error message saying NUL is not a valid file name. Looking at 
grep-use-null-device at this point, shows it is set to t. First time, it 
is tested and set to nil (I checked), second time, because the test is 
executed again due to the above bug, it is somehow set to t. The only 
difference between the two test runs is, that the second time the 
grep-command is actually set and the grep-probe is executing the stored 
command. However, the command is exactly the same: grep -nH. Note, that 
the -e option is missing. I stepped through the code and the test for 
the -e options always fails on these XP machines.

I am not quite sure what exactly the test is doing (from line 541 in 
grep.el) but for some reason it does not work under XP. I use GnuWin32 
coreutils, grep, findutils etc. which are correctly added to PATH and 
exec-path in Emacs.

Now, I have a Windows 7 machine, which runs the exact same setup, i.e. 
same .emacs.d, GnuWin32 utils, path setup and on it, everything works 
fine and the grep options are shown as expected: grep -nH -e.

The interesting part is that on this machine the above described bug has 
no effect. Where on my XP machines the second test for 
grep-use-null-device shows a different result than the first test, on 
Windows 7 both test results are the same and grep-use-null-device stays 
nil. This despite (or because of?) the fact that the first test is 
executed with grep -nH and the second test with grep -nH -e, since the 
-e option was added to grep-command.

I guess I need more information on what the -e test is actually doing to 
debug this.

Does anybody else have this problem under Windows?

Thanks,
Christoph




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2010-04-08  2:35 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-08  2:35 Weird grep.el behavior Christoph

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.