[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment
From: |
Noam Postavsky |
Subject: |
bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect |
Date: |
Thu, 17 Nov 2016 16:27:17 -0500 |
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?
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Óscar Fuentes, 2016/11/16
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Noam Postavsky, 2016/11/17
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Eli Zaretskii, 2016/11/17
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect,
Noam Postavsky <=
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Eli Zaretskii, 2016/11/18
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Noam Postavsky, 2016/11/18
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Eli Zaretskii, 2016/11/19
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Noam Postavsky, 2016/11/21
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Eli Zaretskii, 2016/11/22
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Noam Postavsky, 2016/11/22
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Eli Zaretskii, 2016/11/23
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Óscar Fuentes, 2016/11/27
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, npostavs, 2016/11/27
- bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect, Noam Postavsky, 2016/11/28