bug#20744: shell-quote-argument in Emacs 24.5 and Emacs 25 on Windows cannot figure out path correctly

[Da Zhang]

Hello Eli,

Thanks for looking into this again. The change I made is a very ugly hack, and I did not use it actually -- instead, I just changed the python.el to avoid using shell-quote-argument.
For work reason I have to use Windows, but I do use cygwin bash as my working shell and it's convenient to have emacs and bash together, such as in dired, grep, etc.
I understand using cmd.exe could solve the problem, but I am reporting this issue in subr.el, particularly, shell-quote-argument, because I think the current code is forcing Windows users to use the cmd shell.

In fact, I did not see such a problem before Emacs 24.3. There might be some changes since then. In addition, there is a 10-years old post in
http://lists.gnu.org/archive/html/emacs-devel/2005-03/msg00313.html
talking about the similar problem, and the lister mentioned
"

It seems very usual for emacs users on w32 to use cygwin or mingw.
Right now shell-quote-argument would return something wrong when bash
or some "intelligent" shell is used on w32 because it assumes a dumb
w32 shell.

"

I am no expert in this this fundamental lisp model of subr.el, and the consequence of changing it. That's why I am reporting this as a bug in the hope some higher experts could lend some help.

Thanks.

Da Zhang

On 6/5/2015 4:13 PM, Eli Zaretskii wrote:

Date: Fri, 05 Jun 2015 12:33:59 -0400
From: Da Zhang <zhangda82@gmail.com>

I use python mode (python.el) for some python programming. When I invoke
the command python-shell-send-buffer, my Emacs always reports "Searching
for program: no such file or directory,
c\:/Anaconda3/Scripts/ipython.exe".

I traced down the cause of this problem, and found the following lines
in python.el:
(defun python-shell-parse-command () ;FIXME: why name it "parse"?
"Calculate the string used to execute the inferior Python process."
;; FIXME: process-environment doesn't seem to be used anywhere within
;; this let.
(let ((process-environment (python-shell-calculate-process-environment))
(exec-path (python-shell-calculate-exec-path)))
(format "%s %s"
;; FIXME: Why executable-find?
(shell-quote-argument (executable-find python-shell-interpreter))
python-shell-interpreter-args)))

The function call 
(shell-quote-argument (executable-find python-shell-interpreter))
changed the path of my python interpreter from
"c:/Anaconda3/Scripts/ipython.exe"
to
"c\\:/Anaconda3/Scripts/ipython.exe".

I worked around this problem by replacing the function call
(shell-quote-argument (executable-find python-shell-interpreter))
with
(executable-find python-shell-interpreter) ;; edited by DZ on
2015/06/05: (shell-quote-argument) caused the problem of
"c\\:/Anaconda3/Scripts/ipython.exe"

To further analyze the problem, I found the function
shell-quote-argument defined in subr.el does not deal with the case when
bash from cygwin is used.

For the record, this is bug #20237.

I added the following lines in the cond statement, to solve the problem.
((and (eq system-type 'windows-nt) (if (string-match ".*cygwin.*"
(w32-shell-name)) t nil)) ;; DZ's edit on 6/5/2015
(if (equal argument "")
"''"
;; Quote everything except POSIX filename characters.
;; This should be safe enough even for really weird shells.
(replace-regexp-in-string
"\n" "'\n'"
(replace-regexp-in-string "[^-0-9a-zA-Z_./\n:]" "\\\\\\&" argument))))

I'm sorry, but I don't see how we can accept such a change: it means
that when the Cygwin Bash is used as the shell, the ':' character will
not be quoted, which I think could cause trouble in some cases.

Maybe some Bash expert could chime in and tell whether problems are
possible with Bash in this case.

Is there any way you could avoid using the Cygwin Bash as the shell
when running the native Windows build of Emacs?  That would make the
problem go away without any need for changes.