19 Apr 2012 16:15
Re: SHELL environment variable and the cmdproxy
Bo Johansson <bo.johansson <at> lsn.se>
2012-04-19 14:15:19 GMT
2012-04-19 14:15:19 GMT
>From: Denis Howe
>Date: Wed, 28 Mar 2012 15:11:50 +0100
>On Mon, 2012-02-27 19:00:49 +0100, Bo Johansson wrote:
>> 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.
>Thanks to Bo for a great post about an issue keeps biting me. As Bo
>points out, Emacs' SHELL environment variable breaks some external
>processes (e.g. installing Perl modules), so why set it? Setting it
>to cmdproxy, the default on Windows, will cause other programs running
>in an Emacs subshell to use cmdproxy as a "sh" replacement. Then if
>they try to do "sh -c 'myprog foo bar' ", it will eventually become
>something like "cmd /c myprog foo bar". Clearly only Unix ports
>running on Windows would benefit. Are there any examples where this
>SHELL variable setting actually helps?
>My .emacs now removes SHELL from process-environment, which seems to
>work for me.
Nice it could help somebody. But I want more to be helped!
I have continued to work on the problem. It is a Emacs-w32 problem.
I issued a bug report: bug#10980: 23.4; Variable init_environment incorrectly set see http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00178.html. The bug report did not get enough priority to result in a change.
During the work I have realized that changes to the environment are mainly made for Emacs, NOT for the processes STARTED by Emacs. The elisp code expects a certain situation. Example: "However, Emacs assumes a fully case sensitive environment, so we need to change "Path" to "PATH" to match the expectations of various elisp packages."
--------------------------- My goal
is to get the same result using: 1) The Windows command prompt, 2) The Emacs compile function or 3) The Emacs shell-command function. An example: To do "make" from a Windows command prompt, to do (compile "make" nil) or to do (shell-command "make" nil nil) should all give the same result.
--------------------------- Proposal: Better warning message from the cmdproxy.exe
if (argc > 0) warn ("warning: extra args ignored after '%s'\n", argv[-1]);
is 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.
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 ... ".
This change will help people to understand what is going on until the problem is solved.
--------------------------- Proposal: Programming rules how to handle environment variables
There is a need for rules how to use and change the environment variables in Emacs.
In Emacs the "internal environment" used internally in Emacs and the external used to set up external processes should probably be separated.
--------------------------- Proposal: Read-only "inherited environment"
Implement a lisp function to get the "inherited environment". This could be achieved by:
1) To save the "inherited environment" early in "c-code" at start up of Emacs
2) Implement a lisp function which can return the saved "inherited environment".
To change the current handling of the variable initial-environment is probably difficult and error prone.
The feature to read the "inherited environment" is a first step in handling the "external environment", which is used used to set up external processes.
The feature can then later be used to start external processes with a more "transparent" environment.
--------------------------- Proposal: Strategy for an invisible cmdproxy.exe
The SHELL environment variable should have it "normal" value both when running M-x compile and M-! (= shell-command). 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.
I have the feeling that the adaptation to Windows sometimes is done twice. First by cmdproxy.exe and than by the called utilities.
The documentation of the cmdproxy.exe is rather limited!?
Denis, what do you think is a feasible way to solve the problems? Is there any clean solution.