|
From: | Bo Johansson |
Subject: | Re: [h-e-w] SHELL environment variable and the cmdproxy |
Date: | Thu, 19 Apr 2012 16:15:19 +0200 |
>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 |
[Prev in Thread] | Current Thread | [Next in Thread] |