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
next prev parent 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.