bug#67540: 29.1; Emacs on Windows incorrectly capitalizes some environment variables

[Dave Abrahams]

On Nov 29, 2023, at 11:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:

Date: Wed, 29 Nov 2023 19:42:46 -0800
From: Jim Porter <jporterbugs@gmail.com>

On 11/29/2023 6:29 PM, Dave Abrahams wrote:

Now issue the "set" command from a CMD shell. Notice that the "Path"
environment variable has been renamed to "PATH" in Emacs.  This renaming
interferes with some tools operating correctly e.g. the swift compiler
(see https://swift.org).

This sounds like there's a bug in the Swift compiler. Environment 
variables on MS-Windows are case-insensitive: 
<https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-wgetenv?view=msvc-170>. 
That documentation just covers 'getenv' (and 'wgetenv'), but I'm 
reasonably certain the same applies to the Win32 APIs as well.

Right.

It might be nice for Emacs to preserve the case of any existing 
environment variables on MS-Windows to be on the safe side though...

That's impossible in practice: we'd need to "fix" every single Lisp
program and every place in the Emacs C code that compare against
"PATH" case-sensitively.  And what about user confusion, for those of
us who mostly work on Unix, but sometimes need to work on Windows?

I don't think this is that hard to fix without breaking anybody.  Simply maintain a mapping of in-Emacs upcased environment variable names to the lowercased counterparts from which they came, and map back when setting up a process environment.

We decided long ago to make these letter-case changes in the Windows
build of Emacs, and the decision held well since then.  I see no
reason to change that decision now, just because some program
misbehaves on Windows.

“My” Windows expert told me that “Path is the correct spelling,” or I wouldn't have reported this as a bug.  Still, I think you could make the workaround described above, if you wanted to accomodate my "misbehaving" tools.