emacs-devel
[Top][All Lists]
Advanced

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

Weird grep.el behavior


From: Christoph
Subject: Weird grep.el behavior
Date: Wed, 07 Apr 2010 20:35:30 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

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




reply via email to

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