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: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: bo.johansson <at> lsn.se, 10980 <at> debbugs.gnu.org
Subject: bug#10980: GNU bugs information: logs for bug#10980
Date: Wed, 29 Jun 2016 18:15:44 +0300
> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Wed, 29 Jun 2016 09:12:39 -0400
> Cc: 10980 <at> debbugs.gnu.org, bo.johansson <at> lsn.se
> 
> On Wed, Jun 22, 2016 at 10:57 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > In any case, doing that would mean a much larger job, even if it's
> > possible.  E.g., how do you deal with Lisp code that expects
> > (expand-file-name "~") and (getenv "HOME") to yield the same value?
> 
> Hmm, so it's easy enough to move setting of both Vprocess_environment
> and Vinitial_environment before the Windows code starts adding to the
> environment.

I'd actually suggest doing it the other way around: move the
Windows-specific code in w32.c that pushes these variables into the
environment after Vprocess_environment and Vinitial_environment were
already computed.  That way, we are sure the only affected platform is
w32.  (Order of initialization at startup matters, so best not to rock
the boat there, unless we absolutely have to.)

> And getenv would have to be modified to consult Emacs'
> environment so that that (expand-file-name "~") and (getenv "HOME")
> give the same values.

C 'getenv' or Lisp 'getenv'?

> But it seems we would then need 2 sets of functions: getenv/setenv and
> get-subproc-env/set-subproc-env (the latter working on
> Vprocess_environment only). This feels like a complication with not
> much benefit.

We already have that: there's 'getenv' and 'egetenv' on the C level.
And the Lisp 'setenv' is already documented to modify
process-environment.  So I'm not sure I see the problem (although it's
clear that getenv_internal_1 will probably need some Windows specific
changes.)




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.