RE: problem using call-process with grep

From:

Drew Adams

Subject:

RE: problem using call-process with grep

Date:

Fri, 23 Dec 2005 17:51:04 -0800

To figure out whether this is specific to Cygwin `grep' or a property of
`call-process', could someone else (e.g. on GNU/Linux) please try these:
(call-process "/path/to/your/echo" nil t nil "foo\\\\(bar\\\\)")
(call-process "/path/to/your/echo" nil t nil "foo\\(bar\\)")
In my case, the first gives: foo\(bar\); the second gives foo(bar).
Feedback from someone on GNU/Linux:
system-configuration
=> "i386-pc-linux-gnu"
(call-process "/bin/echo" nil t nil
"\\x \\\\x \\(x\\) \\\\(x\\\\)")
=> 0
=| \x \\x \(x\) \\(x\\)
(call-process "/bin/sh" nil t nil "-c"
"echo '\\x \\\\x \\(x\\) \\\\(x\\\\)'")
=> 0
=| \x \\x \(x\) \\(x\\)
identical results for buffers in text and emacs lisp modes.
I misstated the test, above. This doesn't tell us anything about `grep',
obviously.
Do the tests mean that there is a problem in the native Windows
implementation of `call-process'? Could they mean that there is a problem in
all Cygwin processes?
IIUC, `call-process' doesn't spawn a shell, so if this were a problem on the
Cygwin end, then it would have to be a problem for each of `grep', `echo',
and `sh' (commands tested so far) that doesn't manifest itself from the
command line. Or am I missing something else?
Could someone who works on the Windows port perhaps take a look to see if
`call-process' is doing the right thing? It would seem surprising for this
to turn out to be a bug in that code, since this behavior is old (at least
since Emacs 20) and it occurs in such a prominent place. I'd think that this
would have already been pounded on enough to expose any problem of this
kind.