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

[Bo Johansson]

>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