> On Nov 29, 2023, at 11:22 PM, Eli Zaretskii wrote: > >> Date: Wed, 29 Nov 2023 19:42:46 -0800 >> From: Jim Porter >> >> 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: >> . >> 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.