bug#10980: GNU bugs information: logs for bug#10980

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

severity 10980 wishlist
quit

> From: "Bo Johansson" <bo.johansson <at> lsn.se>
> To: "Eli Zaretskii" <eliz <at> gnu.org>
> Cc: 10980 <at> debbugs.gnu.org
> Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set
> Date: Wed, 28 Mar 2012 10:56:44 +0200
>
> 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.
>

I read this as a feature request to let lisp programs be able to see
the environment from before Emacs startup routines have changed it. I
have an additional use case for this: in magit it would be useful to
see if the user has HOME or if they just let Emacs choose a default
value for it.  In the latter case, I would pop up a warning to tell
them not to do that because git chooses a different default value
HOME, and having disagreement causes confusion (of the "why does X
work from command line and not in magit?" variety).

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 7 Jun 2016 23:54:17 -0400
> Cc: bo.johansson@lsn.se
> 
> > 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.
> >
> 
> I read this as a feature request to let lisp programs be able to see
> the environment from before Emacs startup routines have changed it.

I don't think we want to have environment-related functions that are
specific to Windows, that goes against the goal of portability of
Emacs packages.

I'm okay with considering patches specific to w32 that would eliminate
the need for pushing variables into the environment of subprocesses,
and/or leave initial-environment unaffected by the pushed values, but
no one has stepped forward for the job.

> I have an additional use case for this: in magit it would be useful
> to see if the user has HOME or if they just let Emacs choose a
> default value for it.  In the latter case, I would pop up a warning
> to tell them not to do that because git chooses a different default
> value HOME, and having disagreement causes confusion (of the "why
> does X work from command line and not in magit?" variety).

I guess you refer to the fact that msysgit uses $USERPROFILE as the
alternative home directory if $HOME is not set?  If so, I'd rather
suggest to report a bug to msysgit maintainers: they are behaving
against platform recommendations.  From
https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx:

  CSIDL_PROFILE
  FOLDERID_Profile

    The user's profile folder. A typical path is
    C:\Users\username. Applications should not create files or folders
    at this level; they should put their data under the locations
    referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. However, if you
    are creating a new Known Folder the profile root referred to by
    CSIDL_PROFILE is appropriate.

If you look in the $USERPROFILE directory on a typical Windows
machine, you won't see there any sub-directory or file created by an
application, only a few standard sub-directories.  Applications do
generally follow the above recommendations; for example, I have
Firefox installed, which keeps my customizations in
$APPDATA/Mozilla/Firefox/Profiles/.  So Git is the odd one out if it
puts its ~/.gitconfig file in $USERPROFILE.

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Wed, Jun 8, 2016 at 12:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> I don't think we want to have environment-related functions that are
> specific to Windows, that goes against the goal of portability of
> Emacs packages.
>
> I'm okay with considering patches specific to w32 that would eliminate
> the need for pushing variables into the environment of subprocesses,
> and/or leave initial-environment unaffected by the pushed values

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.

> I guess you refer to the fact that msysgit uses $USERPROFILE as the
> alternative home directory if $HOME is not set?  If so, I'd rather
> suggest to report a bug to msysgit maintainers: they are behaving
> against platform recommendations.
[...]
> If you look in the $USERPROFILE directory on a typical Windows
> machine, you won't see there any sub-directory or file created by an
> application, only a few standard sub-directories.  Applications do
> generally follow the above recommendations; for example, I have
> Firefox installed, which keeps my customizations in
> $APPDATA/Mozilla/Firefox/Profiles/.  So Git is the odd one out if it
> puts its ~/.gitconfig file in $USERPROFILE.

To me it makes sense to have $HOME map to $USERPROFILE, and $APPDATA
is like $XDG_CONFIG_HOME (usually ~/.config/ on GNU/Linux). However,
this is purely subjective as there are no platform recommendations
about translating environment variables to other platforms.

[-- Attachment #2: 0001-Set-Vinitial_environment-before-changing-env-vars.patch --]
[-- Type: application/octet-stream, Size: 3432 bytes --]

From d67fb15fdcd7a742ce0bb7963ddcfea430f7ef19 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Mon, 20 Jun 2016 20:08:15 -0400
Subject: [PATCH] Set Vinitial_environment before changing env vars

* src/callproc.c (make_list_from_environ): Renamed from
set_initial_environment, just return a Lisp list of the environment
instead of setting of Vprocess_environment and Vinitial_environment
directly.
* src/emacs.c (main): Set Vinitial_environment before init_environment
is called so that it gets the initial environment inherited from the
parent process and remains unaffected by modifications Emacs
performs (Bug #10980).
---
 src/callproc.c | 12 +++++-------
 src/emacs.c    | 14 ++++++++------
 src/lisp.h     |  2 +-
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/callproc.c b/src/callproc.c
index 0729782..924b755 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1577,16 +1577,14 @@ init_callproc (void)
 #endif
 }
 
-void
-set_initial_environment (void)
+Lisp_Object
+make_list_from_environ (void)
 {
   char **envp;
+  Lisp_Object list = Qnil;
   for (envp = environ; *envp; envp++)
-    Vprocess_environment = Fcons (build_string (*envp),
-				  Vprocess_environment);
-  /* Ideally, the `copy' shouldn't be necessary, but it seems it's frequent
-     to use `delete' and friends on process-environment.  */
-  Vinitial_environment = Fcopy_sequence (Vprocess_environment);
+    list = Fcons (build_string (*envp), list);
+  return list;
 }
 
 void
diff --git a/src/emacs.c b/src/emacs.c
index bb85733..1dbb3f6 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1210,10 +1210,17 @@ Using an Emacs configured with --with-x-toolkit=lucid does not have this problem
 #ifdef HAVE_WINDOW_SYSTEM
       init_fringe_once ();	/* Swap bitmaps if necessary.  */
 #endif /* HAVE_WINDOW_SYSTEM */
+
+      /* Initialize and GC-protect Vinitial_environment and Vprocess_environment
+         before filling them in.  */
+      syms_of_callproc ();
     }
 
   init_alloc ();
 
+  if (! dumping)
+    Vinitial_environment = make_list_from_environ ();
+
   if (do_initial_setlocale)
     {
       fixup_locale ();
@@ -1366,16 +1373,11 @@ Using an Emacs configured with --with-x-toolkit=lucid does not have this problem
   ns_init_locale ();
 #endif
 
-  /* Initialize and GC-protect Vinitial_environment and
-     Vprocess_environment before set_initial_environment fills them
-     in.  */
-  if (!initialized)
-    syms_of_callproc ();
   /* egetenv is a pretty low-level facility, which may get called in
      many circumstances; it seems flimsy to put off initializing it
      until calling init_callproc.  Do not do it when dumping.  */
   if (! dumping)
-    set_initial_environment ();
+    Vprocess_environment = make_list_from_environ ();
 
   /* AIX crashes are reported in system versions 3.2.3 and 3.2.4
      if this is not done.  Do it after set_global_environment so that we
diff --git a/src/lisp.h b/src/lisp.h
index e0eb52a..33e1f70 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4199,7 +4199,7 @@ extern void setup_process_coding_systems (Lisp_Object);
 extern int child_setup (int, int, int, char **, bool, Lisp_Object);
 extern void init_callproc_1 (void);
 extern void init_callproc (void);
-extern void set_initial_environment (void);
+extern Lisp_Object make_list_from_environ (void);
 extern void syms_of_callproc (void);
 
 /* Defined in doc.c.  */
-- 
2.6.2.windows.1

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 20 Jun 2016 20:23:26 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> > I'm okay with considering patches specific to w32 that would eliminate
> > the need for pushing variables into the environment of subprocesses,
> > and/or leave initial-environment unaffected by the pushed values
> 
> 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, something
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?

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.
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.

> > If you look in the $USERPROFILE directory on a typical Windows
> > machine, you won't see there any sub-directory or file created by an
> > application, only a few standard sub-directories.  Applications do
> > generally follow the above recommendations; for example, I have
> > Firefox installed, which keeps my customizations in
> > $APPDATA/Mozilla/Firefox/Profiles/.  So Git is the odd one out if it
> > puts its ~/.gitconfig file in $USERPROFILE.
> 
> To me it makes sense to have $HOME map to $USERPROFILE, and $APPDATA
> is like $XDG_CONFIG_HOME (usually ~/.config/ on GNU/Linux). However,
> this is purely subjective as there are no platform recommendations
> about translating environment variables to other platforms.

I quoted the platform recommendations that discourage putting files
directly under $USERPROFILE, and most programs, including those ported
from Posix platforms, do seem to follow those recommendations.

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

On Tue, Jun 21, 2016 at 9:27 AM, Eli Zaretskii <eliz@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.

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 21 Jun 2016 17:03:21 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> I feel like I'm missing some important point here. If these
> environment variables won't affect subprocess environments, why set
> them at all?

Because Emacs itself needs them.  They must be in Emacs's environment,
but don't have to be in Vprocess_environment.

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

On Tue, Jun 21, 2016 at 10:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Tue, 21 Jun 2016 17:03:21 -0400
>> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
>>
>> I feel like I'm missing some important point here. If these
>> environment variables won't affect subprocess environments, why set
>> them at all?
>
> Because Emacs itself needs them.  They must be in Emacs's environment,
> but don't have to be in Vprocess_environment.

What does it need them for? Just because Emacs consults the values
from its environment? Is there some reason not to use just plain old
global variables?

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 21 Jun 2016 22:54:25 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> On Tue, Jun 21, 2016 at 10:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Noam Postavsky <npostavs@users.sourceforge.net>
> >> Date: Tue, 21 Jun 2016 17:03:21 -0400
> >> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> >>
> >> I feel like I'm missing some important point here. If these
> >> environment variables won't affect subprocess environments, why set
> >> them at all?
> >
> > Because Emacs itself needs them.  They must be in Emacs's environment,
> > but don't have to be in Vprocess_environment.
> 
> What does it need them for?

Various features in Emacs rely on them to be present and valid
(because that's what happens on Posix systems).

> Just because Emacs consults the values from its environment?

Yes.

> Is there some reason not to use just plain old global variables?

On all platforms, or just on Windows?

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?

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

On Wed, Jun 22, 2016 at 10:57 AM, Eli Zaretskii <eliz@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. And getenv would have to be modified to consult Emacs'
environment so that that (expand-file-name "~") and (getenv "HOME")
give the same values.

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.

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 29 Jun 2016 09:12:39 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> On Wed, Jun 22, 2016 at 10:57 AM, Eli Zaretskii <eliz@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.)

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

On Wed, Jun 29, 2016 at 11:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> 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'?

Sorry, I meant 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

What about a lisp program that expects (expand-file-name "~") and
(getenv "HOME") to give the same results after running (setenv "HOME"
<whatever>)

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 29 Jun 2016 11:26:04 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> >> 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
> 
> What about a lisp program that expects (expand-file-name "~") and
> (getenv "HOME") to give the same results after running (setenv "HOME"
> <whatever>)

The changes in getenv_internal_1 (or, rather, in getenv_internal) that
I mentioned will have to make that happen.  It already does something
similar.

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Wed, Jun 29, 2016 at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Wed, 29 Jun 2016 11:26:04 -0400
>> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
>>
>> >> 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
>>
>> What about a lisp program that expects (expand-file-name "~") and
>> (getenv "HOME") to give the same results after running (setenv "HOME"
>> <whatever>)
>
> The changes in getenv_internal_1 (or, rather, in getenv_internal) that
> I mentioned will have to make that happen.  It already does something
> similar.

Ah, I think I missed the idea that changing Vprocess_environment would
still affect Emacs' environment (technically, what Emacs thinks its
environment is, which has the same effect). Patch attached.

[-- Attachment #2: v2-0001-Keep-w32-environment-settings-internal-only.patch --]
[-- Type: application/octet-stream, Size: 2877 bytes --]

From 003a86a1779694d9b5aaa44d5557854dd9c2dceb Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 29 Jun 2016 18:52:57 -0400
Subject: [PATCH v2] Keep w32 environment settings internal only

* src/emacs.c (main): For WINDOWSNT platform, move init_environment
calls after the set_initial_environment call.  This prevents Emacs'
modifications to the environment from contaminating Vprocess_environment
and Vinitial_environment (Bug #10980).
* src/callproc.c (getenv_internal): Consult Emacs' internal environment
in as a fallback to Vprocess_environment on WINDOWSNT platforms.
---
 src/callproc.c | 14 ++++++++++++++
 src/emacs.c    | 24 ++++++++++++++----------
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/src/callproc.c b/src/callproc.c
index 7008b91..7880238 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1375,6 +1375,20 @@ getenv_internal (const char *var, ptrdiff_t varlen, char **value,
 			 Vprocess_environment))
     return *value ? 1 : 0;
 
+  /* On Windows we make some modifications to Emacs' enviroment
+     without recording them in Vprocess_environment.  */
+#ifdef WINDOWSNT
+  {
+    char* tmpval = getenv (var);
+    if (tmpval)
+      {
+        *value = tmpval;
+        *valuelen = strlen(tmpval);
+        return 1;
+      }
+  }
+#endif
+
   /* For DISPLAY try to get the values from the frame or the initial env.  */
   if (strcmp (var, "DISPLAY") == 0)
     {
diff --git a/src/emacs.c b/src/emacs.c
index bb85733..f977289 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1351,16 +1351,6 @@ Using an Emacs configured with --with-x-toolkit=lucid does not have this problem
   globals_of_gfilenotify ();
 #endif
 
-#ifdef WINDOWSNT
-  globals_of_w32 ();
-#ifdef HAVE_W32NOTIFY
-  globals_of_w32notify ();
-#endif
-  /* Initialize environment from registry settings.  */
-  init_environment (argv);
-  init_ntproc (dumping); /* must precede init_editfns.  */
-#endif
-
 #ifdef HAVE_NS
   /* Initialize the locale from user defaults.  */
   ns_init_locale ();
@@ -1377,6 +1367,20 @@ Using an Emacs configured with --with-x-toolkit=lucid does not have this problem
   if (! dumping)
     set_initial_environment ();
 
+#ifdef WINDOWSNT
+  globals_of_w32 ();
+#ifdef HAVE_W32NOTIFY
+  globals_of_w32notify ();
+#endif
+  /* Initialize environment from registry settings.  Make sure to do
+     this only after calling set_initial_environment so that
+     Vinitial_environment and Vprocess_environment will contain only
+     variables from the parent process without modifications from
+     Emacs. */
+  init_environment (argv);
+  init_ntproc (dumping); /* must precede init_editfns.  */
+#endif
+
   /* AIX crashes are reported in system versions 3.2.3 and 3.2.4
      if this is not done.  Do it after set_global_environment so that we
      don't pollute Vglobal_environment.  */
-- 
2.6.2.windows.1

bug#10980: GNU bugs information: logs for bug#10980

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 29 Jun 2016 19:02:25 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
> 
> Ah, I think I missed the idea that changing Vprocess_environment would
> still affect Emacs' environment (technically, what Emacs thinks its
> environment is, which has the same effect). Patch attached.

Thanks, please push to master, after fixing the following minor
issues:

> * src/emacs.c (main): For WINDOWSNT platform, move init_environment
> calls after the set_initial_environment call.  This prevents Emacs'
> modifications to the environment from contaminating Vprocess_environment
> and Vinitial_environment (Bug #10980).

Code changes in fragments guarded by preprocessor conditionals should
be formatted like this:

  * src/emacs.c (main) [WINDOWSNT]: Move init_environment calls after ...

> * src/callproc.c (getenv_internal): Consult Emacs' internal environment
> in as a fallback to Vprocess_environment on WINDOWSNT platforms.

Same here.

> +        *valuelen = strlen(tmpval);
                       ^^^^^^^
Please leave a single blank between a function's name and the
following opening parenthesis.

> +  /* Initialize environment from registry settings.  Make sure to do
> +     this only after calling set_initial_environment so that
> +     Vinitial_environment and Vprocess_environment will contain only
> +     variables from the parent process without modifications from
> +     Emacs. */

Please leave 2 blanks between the last period of the comment text and
the comment terminator "*/".

Bonus points for adding a test for this issue.

bug#10980: GNU bugs information: logs for bug#10980

[Noam Postavsky]

close 10980 25.2
quit

On Sat, Jul 9, 2016 at 6:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks, please push to master, after fixing the following minor
> issues:
[...]
> Bonus points for adding a test for this issue.

Done and done, 73f0715d