* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
@ 2016-11-16 22:22 Óscar Fuentes
2016-11-17 17:59 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Óscar Fuentes @ 2016-11-16 22:22 UTC (permalink / raw
To: 24956
emacs -Q. Evaluate:
(let ((compilation-environment (list "PATH=d:\\foo")))
(compile "echo %PATH%"))
The output is the original contents of PATH. Until recently (June, at
least) it was possible to set PATH in compilation-environment and pass
it to child processes. On GNU/Linux, it still is.
In GNU Emacs 26.0.50.1 (x86_64-w64-mingw32)
of 2016-10-17 built on WIN8-64-VM
Repository revision: 032a299b0ed25f067f4133c547a822b283bc4cb8
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-16 22:22 bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect Óscar Fuentes
@ 2016-11-17 17:59 ` Noam Postavsky
2016-11-17 20:59 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2016-11-17 17:59 UTC (permalink / raw
To: Óscar Fuentes; +Cc: 24956
tag 24956 confirmed
quit
On Wed, Nov 16, 2016 at 5:22 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> emacs -Q. Evaluate:
>
> (let ((compilation-environment (list "PATH=d:\\foo")))
> (compile "echo %PATH%"))
>
> The output is the original contents of PATH. Until recently (June, at
> least) it was possible to set PATH in compilation-environment and pass
> it to child processes. On GNU/Linux, it still is.
It seems that my change in 73f0715d "Keep w32 environment settings
internal only", had an unexpected effect on the way differently cased
environment variables are handled.
With latest master
(let ((process-environment (cons "PATH=d:\\foo" process-environment)))
(call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
inserts the original PATH contents, whereas
(let ((process-environment (cons "Path=d:\\foo" process-environment)))
(call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
inserts "d:\foo". In Emacs 25.1, or reverting the commit I mentioned,
the opposite occurs.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-17 17:59 ` Noam Postavsky
@ 2016-11-17 20:59 ` Eli Zaretskii
2016-11-17 21:27 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2016-11-17 20:59 UTC (permalink / raw
To: Noam Postavsky; +Cc: ofv, 24956
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 17 Nov 2016 12:59:19 -0500
> Cc: 24956@debbugs.gnu.org
>
> > (let ((compilation-environment (list "PATH=d:\\foo")))
> > (compile "echo %PATH%"))
> >
> > The output is the original contents of PATH. Until recently (June, at
> > least) it was possible to set PATH in compilation-environment and pass
> > it to child processes. On GNU/Linux, it still is.
>
> It seems that my change in 73f0715d "Keep w32 environment settings
> internal only", had an unexpected effect on the way differently cased
> environment variables are handled.
>
> With latest master
>
> (let ((process-environment (cons "PATH=d:\\foo" process-environment)))
> (call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
>
> inserts the original PATH contents, whereas
>
> (let ((process-environment (cons "Path=d:\\foo" process-environment)))
> (call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
>
> inserts "d:\foo". In Emacs 25.1, or reverting the commit I mentioned,
> the opposite occurs.
I think this is because PATH doesn't exist in the original environment
inherited from the shell, only Path does. We push PATH into the
environment only in w32.c:init_environment (and do the same trick with
ComSpec vs COMSPEC). But since the above-mentioned change, that
function no longer affects process-environment.
So to fix this bug, we need to push PATH and COMSPEC into
process-environment, replacing their camel-case variants.
Does this make sense?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-17 20:59 ` Eli Zaretskii
@ 2016-11-17 21:27 ` Noam Postavsky
2016-11-18 9:46 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2016-11-17 21:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, 24956
On Thu, Nov 17, 2016 at 3:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Thu, 17 Nov 2016 12:59:19 -0500
>> Cc: 24956@debbugs.gnu.org
>>
>> > (let ((compilation-environment (list "PATH=d:\\foo")))
>> > (compile "echo %PATH%"))
>> >
>> > The output is the original contents of PATH. Until recently (June, at
>> > least) it was possible to set PATH in compilation-environment and pass
>> > it to child processes. On GNU/Linux, it still is.
>>
>> It seems that my change in 73f0715d "Keep w32 environment settings
>> internal only", had an unexpected effect on the way differently cased
>> environment variables are handled.
>>
>> With latest master
>>
>> (let ((process-environment (cons "PATH=d:\\foo" process-environment)))
>> (call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
>>
>> inserts the original PATH contents, whereas
>>
>> (let ((process-environment (cons "Path=d:\\foo" process-environment)))
>> (call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
>>
>> inserts "d:\foo". In Emacs 25.1, or reverting the commit I mentioned,
>> the opposite occurs.
>
> I think this is because PATH doesn't exist in the original environment
> inherited from the shell, only Path does. We push PATH into the
> environment only in w32.c:init_environment (and do the same trick with
> ComSpec vs COMSPEC). But since the above-mentioned change, that
> function no longer affects process-environment.
>
> So to fix this bug, we need to push PATH and COMSPEC into
> process-environment, replacing their camel-case variants.
>
> Does this make sense?
Yes. https://cygwin.com/cygwin-ug-net/using-cygwinenv.html lists a few
other variables that it upcases (at the bottom of the page), should we
do those ones as well?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-17 21:27 ` Noam Postavsky
@ 2016-11-18 9:46 ` Eli Zaretskii
2016-11-18 22:11 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2016-11-18 9:46 UTC (permalink / raw
To: Noam Postavsky; +Cc: ofv, 24956
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 17 Nov 2016 16:27:17 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 24956@debbugs.gnu.org
>
> >> (let ((process-environment (cons "Path=d:\\foo" process-environment)))
> >> (call-process "cmd" nil '(t t) nil "/C" "echo %PATH%"))
> >>
> >> inserts "d:\foo". In Emacs 25.1, or reverting the commit I mentioned,
> >> the opposite occurs.
> >
> > I think this is because PATH doesn't exist in the original environment
> > inherited from the shell, only Path does. We push PATH into the
> > environment only in w32.c:init_environment (and do the same trick with
> > ComSpec vs COMSPEC). But since the above-mentioned change, that
> > function no longer affects process-environment.
> >
> > So to fix this bug, we need to push PATH and COMSPEC into
> > process-environment, replacing their camel-case variants.
> >
> > Does this make sense?
>
> Yes. https://cygwin.com/cygwin-ug-net/using-cygwinenv.html lists a few
> other variables that it upcases (at the bottom of the page), should we
> do those ones as well?
No, I don't think so. (Some of those are up-cased in the original
environment on my machine, anyway.) Let's not do something like that
without a good reason.
Thanks.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-18 9:46 ` Eli Zaretskii
@ 2016-11-18 22:11 ` Noam Postavsky
2016-11-19 7:16 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2016-11-18 22:11 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, 24956
[-- Attachment #1: Type: text/plain, Size: 17 bytes --]
Here is a patch.
[-- Attachment #2: v1-0001-Upcase-Path-and-ComSpec-in-process-environment.patch --]
[-- Type: application/octet-stream, Size: 4061 bytes --]
From b9a9230430c2b7dd5c3c81dacc8277ad7e6cfb32 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 18 Nov 2016 16:26:53 -0500
Subject: [PATCH v1] Upcase Path and ComSpec in process-environment
Since 2016-07-18 "Keep w32 environment settings internal only", the
upcasing of environment variables "Path" and "ComSpec" occured after
initializing process-environment. This meant that Lisp code trying to
override "PATH" environment had no effect (Bug #24956).
* src/w32.c (init_environment): Remove code upcasing "Path" and "ComSpec".
* src/callproc.c (set_initial_environment) [WINDOWSNT]: And put it here,
before adding those variables to process-environment.
---
src/callproc.c | 39 ++++++++++++++++++++++++++++++++++-----
src/w32.c | 19 -------------------
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/src/callproc.c b/src/callproc.c
index dc3ca4a..8736f35 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1607,11 +1607,40 @@ set_initial_environment (void)
{
char **envp;
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);
+ {
+ Lisp_Object envstr = build_string (*envp);
+ Vinitial_environment = Fcons (envstr, Vinitial_environment);
+#ifdef WINDOWSNT
+ /* Special case: on NT, the PATH variable is actually named
+ "Path" although cmd.exe (perhaps NT itself) arranges for
+ environment variable lookup and setting to be case
+ insensitive. However, Emacs assumes a fully case sensitive
+ environment, so we need to change "Path" to "PATH" to match
+ the expectations of various elisp packages. We do this by
+ the sneaky method of modifying the string in the C runtime
+ environ entry.
+
+ The same applies to COMSPEC.
+
+ We want to do this here so that Vprocess_environment is
+ affected by this modification, without getting all the other
+ NT-specific modifications we do in init_environment. */
+ const char *upcased_var = NULL;
+ if (_strnicmp (*envp, "PATH=", 5) == 0)
+ upcased_var = "PATH";
+ else if (_strnicmp (*envp, "COMSPEC=", 8) == 0)
+ upcased_var = "COMSPEC";
+
+ if (upcased_var)
+ {
+ memcpy (*envp, upcased_var, strlen (upcased_var));
+ envstr = build_string (*envp);
+ }
+#endif
+ /* `process_environment' is often modified destructively, so
+ don't share any structure initial-environment. */
+ Vprocess_environment = Fcons (envstr, Vprocess_environment);
+ }
}
void
diff --git a/src/w32.c b/src/w32.c
index ad7d94a..d4a7d93 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -2852,25 +2852,6 @@ init_environment (char ** argv)
/* Rebuild system configuration to reflect invoking system. */
Vsystem_configuration = build_string (EMACS_CONFIGURATION);
- /* Another special case: on NT, the PATH variable is actually named
- "Path" although cmd.exe (perhaps NT itself) arranges for
- environment variable lookup and setting to be case insensitive.
- However, Emacs assumes a fully case sensitive environment, so we
- need to change "Path" to "PATH" to match the expectations of
- various elisp packages. We do this by the sneaky method of
- modifying the string in the C runtime environ entry.
-
- The same applies to COMSPEC. */
- {
- char ** envp;
-
- for (envp = environ; *envp; envp++)
- if (_strnicmp (*envp, "PATH=", 5) == 0)
- memcpy (*envp, "PATH=", 5);
- else if (_strnicmp (*envp, "COMSPEC=", 8) == 0)
- memcpy (*envp, "COMSPEC=", 8);
- }
-
/* Remember the initial working directory for getcwd. */
/* FIXME: Do we need to resolve possible symlinks in startup_dir?
Does it matter anywhere in Emacs? */
--
2.6.2.windows.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-18 22:11 ` Noam Postavsky
@ 2016-11-19 7:16 ` Eli Zaretskii
2016-11-21 23:19 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2016-11-19 7:16 UTC (permalink / raw
To: Noam Postavsky; +Cc: ofv, 24956
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Fri, 18 Nov 2016 17:11:22 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 24956@debbugs.gnu.org
>
> Here is a patch.
Thanks.
Two comments:
. I'd rather have the WINDOWSNT-specific code separate (on w32.c),
so perhaps the for-loop you modified could be left intact, and
instead we perform an additional pass over Vprocess_environment,
after it is already copied, to replace these two variables with
their upper-case equivalents, in that special code on w32.c.
. If you didn't already, please verify that these 2 variables in the
Emacs's own environment are also upcased, because otherwise I
think we will hit more such problems.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-19 7:16 ` Eli Zaretskii
@ 2016-11-21 23:19 ` Noam Postavsky
2016-11-22 16:01 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2016-11-21 23:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, 24956
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
On Sat, Nov 19, 2016 at 2:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> . I'd rather have the WINDOWSNT-specific code separate (on w32.c),
> so perhaps the for-loop you modified could be left intact, and
> instead we perform an additional pass over Vprocess_environment,
> after it is already copied, to replace these two variables with
> their upper-case equivalents, in that special code on w32.c.
Okay, here is a patch that does that.
> . If you didn't already, please verify that these 2 variables in the
> Emacs's own environment are also upcased, because otherwise I
> think we will hit more such problems.
That would be the for loop just above my additions (I increased the
context so it's fully visible in the patch).
[-- Attachment #2: v2-0001-Upcase-Path-and-ComSpec-in-process-environment.patch --]
[-- Type: application/octet-stream, Size: 2099 bytes --]
From 1fe5e0dfb01a0400a90088d44f2f7fc2bd244a43 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 18 Nov 2016 16:26:53 -0500
Subject: [PATCH v2] Upcase Path and ComSpec in process-environment
Since 2016-07-18 "Keep w32 environment settings internal only", the
upcasing of environment variables "Path" and "ComSpec" occured after
initializing process-environment. This meant that Lisp code trying to
override "PATH" environment had no effect (Bug #24956).
* src/w32.c (init_environment): Upcase the "Path" and "ComSpec" entries
in Vprocess_environment.
---
src/w32.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/src/w32.c b/src/w32.c
index ad7d94a..0739e51 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -2867,10 +2867,28 @@ init_environment (char ** argv)
for (envp = environ; *envp; envp++)
if (_strnicmp (*envp, "PATH=", 5) == 0)
memcpy (*envp, "PATH=", 5);
else if (_strnicmp (*envp, "COMSPEC=", 8) == 0)
memcpy (*envp, "COMSPEC=", 8);
+
+ /* Make the same modification to `process-environment' which has
+ already been initialized in set_initial_environment. */
+ Lisp_Object env = Vprocess_environment;
+ Lisp_Object path = build_string ("PATH=");
+ Lisp_Object path_len = make_number (SBYTES (path));
+ Lisp_Object comspec = build_string ("COMSPEC=");
+ Lisp_Object comspec_len = make_number (SBYTES (comspec));
+ for (; CONSP (env); env = XCDR (env))
+ {
+ Lisp_Object entry = XCAR (env);
+ if (EQ (Fcompare_strings (entry, Qnil, path_len, path, Qnil, Qnil, Qt), Qt))
+ for (ptrdiff_t i = 0; i < SBYTES (path); i++)
+ SSET (entry, i, SREF (path, i));
+ else if (EQ (Fcompare_strings (entry, Qnil, comspec_len, comspec, Qnil, Qnil, Qt), Qt))
+ for (ptrdiff_t i = 0; i < SBYTES (comspec); i++)
+ SSET (entry, i, SREF (comspec, i));
+ }
}
/* Remember the initial working directory for getcwd. */
/* FIXME: Do we need to resolve possible symlinks in startup_dir?
Does it matter anywhere in Emacs? */
--
2.6.2.windows.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-21 23:19 ` Noam Postavsky
@ 2016-11-22 16:01 ` Eli Zaretskii
2016-11-22 22:35 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2016-11-22 16:01 UTC (permalink / raw
To: Noam Postavsky; +Cc: ofv, 24956
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 21 Nov 2016 18:19:53 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 24956@debbugs.gnu.org
>
> On Sat, Nov 19, 2016 at 2:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > . I'd rather have the WINDOWSNT-specific code separate (on w32.c),
> > so perhaps the for-loop you modified could be left intact, and
> > instead we perform an additional pass over Vprocess_environment,
> > after it is already copied, to replace these two variables with
> > their upper-case equivalents, in that special code on w32.c.
>
> Okay, here is a patch that does that.
Thanks.
> + /* Make the same modification to `process-environment' which has
> + already been initialized in set_initial_environment. */
> + Lisp_Object env = Vprocess_environment;
> + Lisp_Object path = build_string ("PATH=");
> + Lisp_Object path_len = make_number (SBYTES (path));
> + Lisp_Object comspec = build_string ("COMSPEC=");
> + Lisp_Object comspec_len = make_number (SBYTES (comspec));
> + for (; CONSP (env); env = XCDR (env))
> + {
> + Lisp_Object entry = XCAR (env);
> + if (EQ (Fcompare_strings (entry, Qnil, path_len, path, Qnil, Qnil, Qt), Qt))
> + for (ptrdiff_t i = 0; i < SBYTES (path); i++)
> + SSET (entry, i, SREF (path, i));
> + else if (EQ (Fcompare_strings (entry, Qnil, comspec_len, comspec, Qnil, Qnil, Qt), Qt))
> + for (ptrdiff_t i = 0; i < SBYTES (comspec); i++)
> + SSET (entry, i, SREF (comspec, i));
> + }
Why not compare in using _strnicmp instead of Fcompare_strings? That
would save you the need to cons Lisp strings, and will be more
efficient (Fcompare_strings is quite complex). Not that speed matters
in this case, but it's just looks strange to me. Am I missing
something?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-22 16:01 ` Eli Zaretskii
@ 2016-11-22 22:35 ` Noam Postavsky
2016-11-23 16:07 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2016-11-22 22:35 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, 24956
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Tue, Nov 22, 2016 at 11:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Why not compare in using _strnicmp instead of Fcompare_strings? That
> would save you the need to cons Lisp strings, and will be more
> efficient (Fcompare_strings is quite complex). Not that speed matters
> in this case, but it's just looks strange to me. Am I missing
> something?
Oops. Looking at Fupcase, I had somehow thought that unibyte vs
multibyte would be a problem (and hence I should use Fcompare_strings
to hide the details), but actually (as I think you've mentioned
before) that's not the case for environment variables.
Here's a new patch.
[-- Attachment #2: v3-0001-Upcase-Path-and-ComSpec-in-process-environment.patch --]
[-- Type: application/octet-stream, Size: 2108 bytes --]
From ecb8a7ea028235e67a955e63c5ee1ca5d574b04f Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 18 Nov 2016 16:26:53 -0500
Subject: [PATCH v3] Upcase Path and ComSpec in process-environment
Since 2016-07-18 "Keep w32 environment settings internal only", the
upcasing of environment variables "Path" and "ComSpec" occured after
initializing process-environment. This meant that Lisp code trying to
override "PATH" environment had no effect (Bug #24956).
* src/w32.c (init_environment): Upcase the "Path" and "ComSpec" entries
in Vprocess_environment.
---
src/w32.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/w32.c b/src/w32.c
index ad7d94a..086c1ac 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -2863,12 +2863,29 @@ init_environment (char ** argv)
The same applies to COMSPEC. */
{
char ** envp;
+ const char *path = "PATH=";
+ int path_len = strlen (path);
+ const char *comspec = "COMSPEC=";
+ int comspec_len = strlen (comspec);
for (envp = environ; *envp; envp++)
- if (_strnicmp (*envp, "PATH=", 5) == 0)
- memcpy (*envp, "PATH=", 5);
- else if (_strnicmp (*envp, "COMSPEC=", 8) == 0)
- memcpy (*envp, "COMSPEC=", 8);
+ if (_strnicmp (*envp, path, path_len) == 0)
+ memcpy (*envp, path, path_len);
+ else if (_strnicmp (*envp, comspec, comspec_len) == 0)
+ memcpy (*envp, comspec, comspec_len);
+
+ /* Make the same modification to `process-environment' which has
+ already been initialized in set_initial_environment. */
+ for (Lisp_Object env = Vprocess_environment; CONSP (env); env = XCDR (env))
+ {
+ Lisp_Object entry = XCAR (env);
+ if (_strnicmp (SDATA (entry), path, path_len) == 0)
+ for (int i = 0; i < path_len; i++)
+ SSET (entry, i, path[i]);
+ else if (_strnicmp (SDATA (entry), comspec, comspec_len) == 0)
+ for (int i = 0; i < comspec_len; i++)
+ SSET (entry, i, comspec[i]);
+ }
}
/* Remember the initial working directory for getcwd. */
--
2.6.2.windows.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-22 22:35 ` Noam Postavsky
@ 2016-11-23 16:07 ` Eli Zaretskii
2016-11-27 20:01 ` Óscar Fuentes
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2016-11-23 16:07 UTC (permalink / raw
To: Noam Postavsky; +Cc: ofv, 24956
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 22 Nov 2016 17:35:17 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 24956@debbugs.gnu.org
>
> Oops. Looking at Fupcase, I had somehow thought that unibyte vs
> multibyte would be a problem (and hence I should use Fcompare_strings
> to hide the details), but actually (as I think you've mentioned
> before) that's not the case for environment variables.
>
> Here's a new patch.
Looks OK to me, thanks.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-23 16:07 ` Eli Zaretskii
@ 2016-11-27 20:01 ` Óscar Fuentes
2016-11-27 20:13 ` npostavs
0 siblings, 1 reply; 14+ messages in thread
From: Óscar Fuentes @ 2016-11-27 20:01 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 24956, Noam Postavsky
Eli Zaretskii <eliz@gnu.org> writes:
>> Oops. Looking at Fupcase, I had somehow thought that unibyte vs
>> multibyte would be a problem (and hence I should use Fcompare_strings
>> to hide the details), but actually (as I think you've mentioned
>> before) that's not the case for environment variables.
>>
>> Here's a new patch.
>
> Looks OK to me, thanks.
Ping.
I'll like to mark this as resolved. Noam?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-27 20:01 ` Óscar Fuentes
@ 2016-11-27 20:13 ` npostavs
2016-11-28 22:53 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: npostavs @ 2016-11-27 20:13 UTC (permalink / raw
To: Óscar Fuentes; +Cc: 24956
Óscar Fuentes <ofv@wanadoo.es> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Oops. Looking at Fupcase, I had somehow thought that unibyte vs
>>> multibyte would be a problem (and hence I should use Fcompare_strings
>>> to hide the details), but actually (as I think you've mentioned
>>> before) that's not the case for environment variables.
>>>
>>> Here's a new patch.
>>
>> Looks OK to me, thanks.
>
> Ping.
>
> I'll like to mark this as resolved. Noam?
I'm not in front of my Windows box right now, I'm planning to push this tomorrow.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect
2016-11-27 20:13 ` npostavs
@ 2016-11-28 22:53 ` Noam Postavsky
0 siblings, 0 replies; 14+ messages in thread
From: Noam Postavsky @ 2016-11-28 22:53 UTC (permalink / raw
To: Óscar Fuentes; +Cc: 24956
tag 24956 fixed
close 24956
quit
On Sun, Nov 27, 2016 at 3:13 PM, <npostavs@users.sourceforge.net> wrote:
> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Oops. Looking at Fupcase, I had somehow thought that unibyte vs
>>>> multibyte would be a problem (and hence I should use Fcompare_strings
>>>> to hide the details), but actually (as I think you've mentioned
>>>> before) that's not the case for environment variables.
>>>>
>>>> Here's a new patch.
>>>
>>> Looks OK to me, thanks.
>>
>> Ping.
>>
>> I'll like to mark this as resolved. Noam?
>
> I'm not in front of my Windows box right now, I'm planning to push this tomorrow.
Pushed as 753c565df6 "Upcase Path and ComSpec in process-environment".
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-11-28 22:53 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-16 22:22 bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect Óscar Fuentes
2016-11-17 17:59 ` Noam Postavsky
2016-11-17 20:59 ` Eli Zaretskii
2016-11-17 21:27 ` Noam Postavsky
2016-11-18 9:46 ` Eli Zaretskii
2016-11-18 22:11 ` Noam Postavsky
2016-11-19 7:16 ` Eli Zaretskii
2016-11-21 23:19 ` Noam Postavsky
2016-11-22 16:01 ` Eli Zaretskii
2016-11-22 22:35 ` Noam Postavsky
2016-11-23 16:07 ` Eli Zaretskii
2016-11-27 20:01 ` Óscar Fuentes
2016-11-27 20:13 ` npostavs
2016-11-28 22:53 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).