GNU bug report logs - #10980
23.4; Variable init_environment incorrectly set

Previous Next

Package: emacs;

Reported by: "Bo Johansson" <bo.johansson <at> lsn.se>

Date: Fri, 9 Mar 2012 17:16:03 UTC

Severity: wishlist

Tags: patch

Found in version 23.4

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Bo Johansson" <bo.johansson <at> lsn.se>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 10980 <at> debbugs.gnu.org
Subject: bug#10980: 23.4; Variable initial-environment incorrectly set
Date: Sat, 24 Mar 2012 00:26:06 +0100
>From: Eli Zaretskii
>Sent: Friday, March 23, 2012 10:05 PM
>> From: "Bo Johansson" <bo.johansson <at> lsn.se>
>> Cc: <10980 <at> 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".
>>
>> (See also
>> http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00178.html.)
>
>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.

It is not only about SHELL. But SHELL is the most frequent problem.
Dmake and other make programs is just one among many other cases.

I searched internet for "emacs" and "warning: extra args ignored after". 
There was +1400 hits.
Many of theese depends on that SHELL is set to .../cmdproxy.exe. 
Adding -dmake to the search, resulted in 1280 hits. This indicates that 
dmake is only one case among others.

In the function compilation-start (lisp/progmodes/compile.el:1166) is the 
variable process-environment changed. This is done TEMPORARY by using "(let 
((process-environment ...".  However, in many other places are "persistent" 
changes made by using the lisp function setenv. This is in many cases not 
good. Activating a function can then result in an unexpected "persistent" 
change of the environment.

The last 20 years I have seen many unexpected things using "(compile 
"something" nil)", but it is first lately I have understood that one of the 
reasons are the changed environment.

At least the functions compile and shell-command should use an as far as 
possible unmodified "initial environment inherited by Emacs". I am missing a 
strategy how to handle the environment within Emacs.

I will try to find examples of other variables then SHELL!





This bug report was last modified 8 years and 172 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.