GNU bug report logs - #67540
29.1; Emacs on Windows incorrectly capitalizes some environment variables

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: dave <at> boostpro.com, 67540 <at> debbugs.gnu.org
Subject: bug#67540: 29.1; Emacs on Windows incorrectly capitalizes some environment variables
Date: Thu, 30 Nov 2023 09:22:18 +0200

> Date: Wed, 29 Nov 2023 19:42:46 -0800
> From: Jim Porter <jporterbugs <at> 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?

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.