bug#19817: 24.4; cmdproxy fails on some .exe when given a path argument

[Eli Zaretskii]

> Date: Mon, 09 Feb 2015 21:47:09 +0100
> From: Fabio Leimgruber <fabio.leimgruber@web.de>
> CC: 19817@debbugs.gnu.org
> 
> On 2/9/15 6:43 PM, Eli Zaretskii wrote:
> >>
> >> (defun compile-quoted (command &rest args)
> >>   "Run `compile' with COMMAND and ARGS quoted.
> >>
> >> Useful if you can not be sure if there are special characters in
> >> the command or arguments, like `start-process' allows."
> >>   (let ((compile-command (mapconcat #'shell-quote-argument
> >>                                     (cons command args)
> >>                                     " ")))
> >>     (compile compile-command)))
> >>
> >> (compile-quoted "write" "d:/asdf.txt")
> >>
> >> (compile-quoted "write.test" "d:/asdf.txt")
> > 
> > Thanks, I will look into this.
> > 
> > One question, though: which executable programs should exist in the
> > current directory for this test case to reproduce the problem?  Is the
> > answer write.exe and write.test.exe?  (I'm asking because the original
> > use case seemed to involve a batch file as well, which complicates
> > things quite a lot.)
> > 
> 
> Thanks for looking into this.
> 
> Regarding the executables: originally, this came to attention when we
> tried to call a py.test.exe (installed via Python package manager) from
> the testing machinery of elpy [1] - i.e. no batch files.  AFAICS, the
> problem occurs with any .exe that is renamed so that the file name
> contains a second dot.  I chose write.exe (and a copy renamed to
> write.test.exe) from C:\Windows\System32 for a reproducible example
> because it is already on %PATH% and most likely present on a standard
> Windows system.

There were a few issues in cmdproxy wrt this scenario.  I fixed them
on the emacs-24 branch, please take a look.