RE: problem using call-process with grep

[Drew Adams]

    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.