|
From: | Da Zhang |
Subject: | bug#20744: shell-quote-argument in Emacs 24.5 and Emacs 25 on Windows cannot figure out path correctly |
Date: | Fri, 05 Jun 2015 16:50:46 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
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. |
[Prev in Thread] | Current Thread | [Next in Thread] |