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

[Eli Zaretskii]

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