>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.
Hej Denis! 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 In cmdproxy.c 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. ---- Motivation: 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. ---- Motivation: 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". ---- Motivation: 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. Best regards Bo Johansson
