all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Noam Postavsky <npostavs@users.sourceforge.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org
Subject: bug#10980: GNU bugs information: logs for bug#10980
Date: Wed, 29 Jun 2016 19:02:25 -0400	[thread overview]
Message-ID: <CAM-tV--w2VVUYe4Dod+hcrNykU1i8ZQSGL0xOq-W=uMZV4tzKw@mail.gmail.com> (raw)
In-Reply-To: <838txovwk7.fsf@gnu.org>

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


  reply	other threads:[~2016-06-29 23:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAM-tV-8GBPbR3WO9Y_k6mrWop2ZcJCL16R9R2=zmFU5brRp5+w@mail.gmail.com>
     [not found] ` <handler.s.R.14653322689344.info.0@debbugs.gnu.org>
2016-06-08  3:54   ` bug#10980: GNU bugs information: logs for bug#10980 Noam Postavsky
2016-06-08 16:40     ` Eli Zaretskii
2016-06-21  0:23       ` Noam Postavsky
2016-06-21 13:27         ` Eli Zaretskii
2016-06-21 21:03           ` Noam Postavsky
2016-06-22  2:39             ` Eli Zaretskii
2016-06-22  2:54               ` Noam Postavsky
2016-06-22 14:57                 ` Eli Zaretskii
2016-06-29 13:12                   ` Noam Postavsky
2016-06-29 15:15                     ` Eli Zaretskii
2016-06-29 15:26                       ` Noam Postavsky
2016-06-29 15:34                         ` Eli Zaretskii
2016-06-29 23:02                           ` Noam Postavsky [this message]
2016-07-09 10:57                             ` Eli Zaretskii
2016-07-18 21:52                               ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM-tV--w2VVUYe4Dod+hcrNykU1i8ZQSGL0xOq-W=uMZV4tzKw@mail.gmail.com' \
    --to=npostavs@users.sourceforge.net \
    --cc=10980@debbugs.gnu.org \
    --cc=bo.johansson@lsn.se \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.