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

[Dave Abrahams <dave@boostpro.com>]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]



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


[-- Attachment #2: Type: text/html, Size: 10493 bytes --]