bug#8541: start-process fails when both the program path and an argument contain spaces

bug#8541: start-process fails when both the program path and an argument contain spaces

[Ivar Rummelhoff]

1. Trying to execute

    (start-process "name" "buffer" "D:\\tmp\\xxx yyy\\foo.bat" "yada yada")

writes the following to "buffer":

    'd:\tmp\xxx' is not recognized as an internal or external command,
    operable program or batch file.

    Process name exited abnormally with code 1

Emacs version: GNU Emacs 23.3.1 (i386-mingw-nt6.1.7601) of 2011-03-10 on 3249CTO


2. If space is avoided in either the program path or the argument, as in

    (start-process "name" "buffer" "D:\\tmp\\foo.bat" "yada yada")
or
    (start-process "name" "buffer" "D:\\tmp\\xxx yyy\\foo.bat" "yada-yada")

then everything works well.


3. The same problem occurs when I give `start-process' the program
name only (instead of the full path) as long as the full path to the
program contains spaces (and one of the arguments contains spaces).


4. Quoting the program path or the argument (with " or \) does not
help. If quote the program path, I get "no such file or directory";
and quoting the argument has no effect as long as there is still a
space character "in there". (Besides, it seems any quoting of the
arguments is passed on to the program.)


5. There seems to be no work-around for this in emacs lisp.


Best Regards,

Ivar Rummelhoff

bug#8541: start-process fails when both the program path and an argument contain spaces

[Eli Zaretskii]

> Date: Sun, 24 Apr 2011 12:01:17 +0200
> From: Ivar Rummelhoff <ivarru@gmail.com>
> 
> 1. Trying to execute
> 
>     (start-process "name" "buffer" "D:\\tmp\\xxx yyy\\foo.bat" "yada yada")
> 
> writes the following to "buffer":
> 
>     'd:\tmp\xxx' is not recognized as an internal or external command,
>     operable program or batch file.
> 
>     Process name exited abnormally with code 1
> 
> Emacs version: GNU Emacs 23.3.1 (i386-mingw-nt6.1.7601) of 2011-03-10 on 3249CTO
> 
> 
> 2. If space is avoided in either the program path or the argument, as in
> 
>     (start-process "name" "buffer" "D:\\tmp\\foo.bat" "yada yada")
> or
>     (start-process "name" "buffer" "D:\\tmp\\xxx yyy\\foo.bat" "yada-yada")
> 
> then everything works well.
> 
> 
> 3. The same problem occurs when I give `start-process' the program
> name only (instead of the full path) as long as the full path to the
> program contains spaces (and one of the arguments contains spaces).
> 
> 
> 4. Quoting the program path or the argument (with " or \) does not
> help. If quote the program path, I get "no such file or directory";
> and quoting the argument has no effect as long as there is still a
> space character "in there". (Besides, it seems any quoting of the
> arguments is passed on to the program.)

This is due to deficiencies in the Windows API for launching programs
(CreateProcess): it concatenates the command arguments into a single
string, separated by blanks..  To work around, invoke the command
through cmd.exe, and use cmd.exe-specific quoting character '^'.  Like
this:

 (start-process "name" "buffer" "cmd.exe" "/c" "D:\\tmp\\xxx^ yyy\\foo.bat yada^ yada")

This is fragile, and you will need to redo the quoting if you invoke
other programs or have whitespace in other places.  But I don't know
how to do better, given the Windows API misfeatures.  It is best to
avoid whitespace in the arguments.  For file names, you can use 8+3
aliases, if you cannot control the names of the files or directories.

bug#8541: start-process fails when both the program path and an argument contain spaces

[Noam Postavsky]

I believe this was fixed along with #18745 (while searching for it I
happened to stumble upon this one).

A nicer workaround suggested by Eli on that bug is to use w32-short-file-name:

    (start-process "name" "buffer"
                   (w32-short-file-name "D:\\tmp\\xxx yyy\\foo.bat")
                   "yada yada")

bug#8541: start-process fails when both the program path and an argument contain spaces

[Eli Zaretskii]

> Date: Wed, 30 Sep 2015 12:29:41 -0400
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> 
> I believe this was fixed along with #18745 (while searching for it I
> happened to stumble upon this one).

Indeed, so closing this one.