bug-gnu-emacs
[Top][All Lists]
Advanced

[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" <address@hidden>
Cc: <address@hidden>
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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]