[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10980: 23.4; Variable initial-environment incorrectly set
From: |
Bo Johansson |
Subject: |
bug#10980: 23.4; Variable initial-environment incorrectly set |
Date: |
Wed, 28 Mar 2012 10:56:44 +0200 |
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.