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


Message #40 received at 10980 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bo.johansson <at> lsn.se, 10980 <at> debbugs.gnu.org
Subject: Re: bug#10980: GNU bugs information: logs for bug#10980
Date: Tue, 21 Jun 2016 17:03:21 -0400
On Tue, Jun 21, 2016 at 9:27 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> How about splitting apart initialization of Vinitial_environment and
>> Vprocess_environment and moving the former earlier so that it's
>> unaffected by Emacs' manipulations of the environment? See attached
>> patch.
>
> Thanks.  However, I wonder if we could do better.  First, your patch
> only fixed initial-environment, which means Lisp applications will
> need to explicitly use it, and probably only on Windows,

Well, Lisp applications that want the environment as Emacs originally
received it will use initial-environment regardless of platform
(without the patch, on Windows, they get an environment with some
modifications from Emacs).

> that is not the best solution, IMO.  I hoped we could come up with a
> way of pushing the additional variables into Emacs's own environment
> after Vprocess_environment is already computed -- can you try doing
> that?

I feel like I'm missing some important point here. If these
environment variables won't affect subprocess environments, why set
them at all?

>
> In any case, the reasons for calling the same function twice in two
> different places should be explained, at least in the comments, or
> else someone might become confused at some future point in time.

Right.

> Better yet, perhaps only the Windows build should do something like
> that, and the other platforms could continue using the current code
> mostly unaltered, as they don't need this.

Isn't it simpler to do the same thing on all platforms? They don't
need a different approach, but it doesn't hurt either.




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.