Re: problem using call-process with grep

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> 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).

Is your `echo.exe' also a Cygwin executable?  My native Windows
executable gives foo\\(bar\\) and foo\(bar\) respectively, as it does
on GNU/Linux.

FWIW, your original test, wiz.:

    (call-process "grep" nil
                   (generate-new-buffer "Result")
                   nil "epsilon\\($\\)" "foo")

also works for me as expected, but my Grep is not a Cygwin executable,
it's a native Windows executable.

> 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?

It could be, see below.

> IIUC, `call-process' doesn't spawn a shell

It doesn't (unless the command is a shell, of course).

> Could someone who works on the Windows port perhaps take a look to see if
> `call-process' is doing the right thing?

The Windows code invoked by `call-process' does quite a lot with
argument escaping and quoting, see w32proc.c:sys_spawnve.  It does so
for a good reason: Windows executables generally have the globbing
code as part of the program itself, as stock Windows shells don't
handle that.  Thus, to DTRT with special characters, such as shell
wildcard characters, quotes and escaping, the Windows code that
launches subsidiary programs needs to know whether the program being
run is a Cygwin program or a native w32 program, and it needs then to
massage the command-line arguments such that when they wind up in the
child program, they will, after removal of quotes and escape
characters done by the application's code, be in the form you wanted
them to be.

That is quite a feat, but I think the code generally does TRT (in
particular, I see that it doubles every \ for Cygwin subsidiary
programs), although having a mix of Cygwin and non-Cygwin tools will
probably put that code to a hard test.

To see what is being passed to the sub-process, the best way is to put
a breakpoint in w32proc.c:sys_spawnve, right before it is about to
call create_child, and look at the command line it generated.  I don't
have Cygwin executables installed, so I cannot look into this myself.
Don't waste your time on experiments with `echo' and other programs:
that only adds more complexity to the problem, as those other programs
also process their command line, and what you see is a result of that
processing, not what Emacs passed.

It is also possible that w32proc.c:w32_executable_type, which tries to
determine whether the subsidiary program is a Cygwin executable, fails
for some reason, so look at that function's results as well.

On top of that, it could be that Cygwin runtime has changed the way it
parses command-line arguments, and it now expects them to be quoted
differently than what Emacs does.

Finally, AFAIK Drew is using an old build of Emacs, so perhaps trying
this in a newer build is in order.