bug#10980: 23.4; Variable initial-environment incorrectly set

["Bo Johansson" <bo.johansson@lsn.se>]

>From: Eli Zaretskii
>Sent: Friday, March 23, 2012 10:05 PM
>> From: "Bo Johansson" <bo.johansson@lsn.se>
>> Cc: <10980@debbugs.gnu.org>
>> Date: Fri, 23 Mar 2012 21:20:23 +0100
>>
>> Summary: A value in the variable initial-environment according to the
>> documentation makes it possible to "get the same result doing something 
>> from
>> within Emacs as doing it from a Windows command prompt".
>>
>Is this only about SHELL, and only with dmake, or are there other
>variables that get in the way of other programs?  Please be specific;
>the few changes done to the variables outside Emacs are done for a
>good reason, so it's important to know the exact adverse effects of
>that to judge how justified would it be to change the current code.

Hej Eli!

Here is some more information.

I have looked in makefile using http://code.google.com/codesearch. SHELL and 
COMSPEC are frequently used. In some cases is even ComSpec used.
To set SHELL to c:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe 
causes a lot of problems.
The resulting errors are often difficult to find. This partly because the 
warning messages given by cmdproxy.exe is often given without any context.

A program developed to run in Windows, expects a “Windows environment”!?

I have compared the environment variables in different situations. The 
differences between the environment in Windows cmd.exe and the Emacs 
variable initial-environment are:

-ComSpec=C:\Windows\system32\cmd.exe
+COMSPEC=C:\Windows\system32\cmd.exe
+EMACSDATA=c:/Program Files (x86)/GNU Emacs 23.4/etc
+EMACSDOC=c:/Program Files (x86)/GNU Emacs 23.4/etc
+EMACSLOADPATH=c:/Program Files (x86)/GNU Emacs 23.4/site-lisp;c:/Program 
Files (x86)/GNU Emacs 23.4/../site-lisp;c:/Program Files (x86)/GNU Emacs 
23.4/lisp;c:/Program Files (x86)/GNU Emacs 23.4/leim
+EMACSPATH=c:/Program Files (x86)/GNU Emacs 23.4/bin
+LANG=SVE
-Path=...
+PATH=...
+SHELL=c:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe
+TMPDIR=C:\Users\bo\AppData\Local\Temp
+emacs_dir=c:/Program Files (x86)/GNU Emacs 23.4

Comspec and Path are renamed. SHELL is added and set to the cmdproxy.exe.

Differences between initial-environment to shell-command environment are:

+EM_PARENT_PROCESS_ID=...


Differences initial-environment to compile environment are:

+DISPLAY=
+EMACS=t
+EM_PARENT_PROCESS_ID=...
+INSIDE_EMACS=t
-TERM=dumb
+TERM=emacs
+TERMCAP=emacs:co#80:tc=unknown:

This comment in emacs-git/src/w32.c:1778:
/* Another special case: on NT, the PATH variable is actually named
     "Path" although cmd.exe (perhaps NT itself) arranges for
     environment variable lookup and setting to be case insensitive.
     However, Emacs assumes a fully case sensitive environment, so we
     need to change "Path" to "PATH" to match the expectations of
     various elisp packages.  We do this by the sneaky method of
     modifying the string in the C runtime environ entry.

     The same applies to COMSPEC.  */
indicates that changes to the environment are mainly? made for Emacs, NOT 
for the processes started by Emacs. Emacs should separate the "internal 
environment" used internally by Emacs and the external used to set up 
external processes!?

My idea to get a read-only "inherited environment" is:
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".

The new read-only "inherited environment" can then later be used to start 
external processes with a more "transparent" environment.
To start to change the current handling of the variable initial-environment 
is probably difficult and error prone.