help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[h-e-w] SHELL environment variable and the cmdproxy


From: Bo Johansson
Subject: [h-e-w] SHELL environment variable and the cmdproxy
Date: Mon, 27 Feb 2012 19:00:49 +0100

Hej!
 
--------------------------- Background
I am used to "live" in emacs and want to get the same result doing something from within emacs as doing it from a Windows command prompt.
For example (compile "dmake" nil) in emacs and executing dmake in a Windows command window should give the same result.
 
--------------------------- Summary of the problems
The environment variable SHELL has in (my) emacs at start up the value "C:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe". In the Windows command shell it is not defined.
 
Starting dmake from within emacs results in that dmake uses the cmdproxy.exe as shell.
However cmdproxy.exe sometimes does not like all the arguments and issues messages like "warning: extra args ignored after '-e'".
It also truncates the command. The results are unexpected and errors are difficult to find.
 
The logic in the start-up files of dmake (when SHELL is "C:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe")  configure dmake for using a Kornshell compatible shell. This causes a lot of problems.
Often the Windows command shell is started in interactive mode and the action initiated by (compile "dmake" nil) is stuck.
 
--------------------------- Proposal: Better warning message from cmdproxy.exe
The warning messages given by cmdproxy.exe is often given without any context.
It took me a long time to understand that the cmdproxy.exe was the source of the warning message "warning: extra args ignored after ... ".
 
In cmdproxy.c
   if (argc > 0) warn ("warning: extra args ignored after '%s'\n", argv[-1]);
could be changed to
   if (argc > 0) warn ("warning: [cmdproxy.exe] extra args ignored after '%s'\n", argv[-1]);
 
The command with all its args could also be included in the message.
 
--------------------------- SHELL value used in the emacs compile command
I have added the following to the .emacs file. It changes the value of SHELL in the processes created by the compile command.
 
(eval-after-load 'compile
  '(progn
     (setq compilation-environment
           (list
            (format "SHELL=%s" (or (getenv "COMSPEC") (getenv "ComSpec") (getenv "SHELL") ""))
           ))))
 
Is there a better way of doing this?          
 
--------------------------- SHELL value used in the emacs shell-command command
I have not found any way to change the SHELL variable in the processes started by shell-command.
 
How can it be done?
 
--------------------------- SHELL value used in general by emacs
To change the SHELL variable in the processes started by shell-command I added the following to the .emacs file:
 
(setenv "SHELL" (or (getenv "COMSPEC") (getenv "ComSpec") (getenv "SHELL") ""))
 
This  however gives the following warnings (from w32-check-shell-configuration):
 
Warning! The SHELL environment variable uses C:\Windows\system32\cmd.exe.
You probably want to change it so that it uses cmdproxy.exe instead.
 
Warning! shell-command-switch is "-c".
You should set this to "/c" when using a system shell.
 
Warning! w32-quote-process-args is t.
You should set this to nil when using a system shell.
 
Where is the environment variable SHELL for emacs set?
Can this be done in a better way?
 
--------------------------- Strategy for an invisible cmdproxy.exe
To get the same result by doing something in emacs as by doing it from a Windows command prompt, the cmdproxy.exe should be "invisible".
To do "make" at a Windows command prompt or doing it by M-x compile should (must?) give the same result!?
 
The SHELL environment variable should have it "normal" value both when running M-x compile and  M-! (= shell-command). Normal value is value of SHELL in the Windows command shell. SHELL should never have the value " ... /bin/cmdproxy.exe"!?
 
The purpose of the cmdproxy.exe should only be to translate "emacs internal UNIX-style" commands to those used in the actual Windows command shell.
 
Best regards
Bo Johansson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]