bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect

[Noam Postavsky <npostavs@users.sourceforge.net>]

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?