Emacs 25.2, win64, env vars

Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

Hi,

I might have found a bug in the way Emacs is handling environment variables
under Windows.

I start Emacs with -Q and I can do the following :

(getenv "TEMP")
"C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
(getenv "temp")
"C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"

(setenv "TEMP" "c:/Temp/")
"c:/Temp/"
(getenv "TEMP")
"C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
(getenv "temp")
"C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"

(setenv "temp" "c:/Temp/")
"c:/Temp/"
(getenv "TEMP")
"c:/Temp/"
(getenv "temp")
"c:/Temp/"

AFAIK, environment variables are case insensitive under Windows.
So there is something that is not taken care of for the case of case
insensitive environment variables.
I haven't (yet) been able to find where this magic happens however.

Any idea about where to look for will be welcome :-)

Regards,

Fabrice

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

Re: Emacs 25.2, win64, env vars

[Noam Postavsky]

On Sun, Jun 11, 2017 at 4:33 PM, Fabrice Popineau
<fabrice.popineau@gmail.com> wrote:

> AFAIK, environment variables are case insensitive under Windows.
> So there is something that is not taken care of for the case of case
> insensitive environment variables.
> I haven't (yet) been able to find where this magic happens however.

It looks like there is code for it in callproc.c:

static bool
getenv_internal_1 (const char *var, ptrdiff_t varlen, char **value,
           ptrdiff_t *valuelen, Lisp_Object env)
{
  for (; CONSP (env); env = XCDR (env))
    {
      Lisp_Object entry = XCAR (env);
      if (STRINGP (entry)
      && SBYTES (entry) >= varlen
#ifdef WINDOWSNT
      /* NT environment variables are case insensitive.  */
      && ! strnicmp (SSDATA (entry), var, varlen)

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

Hi,

Thanks Noam.
Yes, the case is handled for getenv.
The problem seems to be with setenv.
The following is a possible fix.

diff --git a/lisp/env.el b/lisp/env.el
index 859f280802..c93be80e84 100644
--- a/lisp/env.el
+++ b/lisp/env.el
@@ -105,7 +105,7 @@ setenv-internal
   "Set VARIABLE to VALUE in ENV, adding empty entries if KEEP-EMPTY.
 Changes ENV by side-effect, and returns its new value."
   (let ((pattern (concat "\\`" (regexp-quote variable) "\\(=\\|\\'\\)"))
-       (case-fold-search nil)
+       (case-fold-search (memq system-type '(ms-dos windows-nt))
        (scan env)
        prev found)
     ;; Handle deletions from the beginning of the list specially.

Fabrice

2017-06-11 23:33 GMT+02:00 Noam Postavsky <npostavs@users.sourceforge.net>:

> On Sun, Jun 11, 2017 at 4:33 PM, Fabrice Popineau
> <fabrice.popineau@gmail.com> wrote:
>
> > AFAIK, environment variables are case insensitive under Windows.
> > So there is something that is not taken care of for the case of case
> > insensitive environment variables.
> > I haven't (yet) been able to find where this magic happens however.
>
> It looks like there is code for it in callproc.c:
>
> static bool
> getenv_internal_1 (const char *var, ptrdiff_t varlen, char **value,
>            ptrdiff_t *valuelen, Lisp_Object env)
> {
>   for (; CONSP (env); env = XCDR (env))
>     {
>       Lisp_Object entry = XCAR (env);
>       if (STRINGP (entry)
>       && SBYTES (entry) >= varlen
> #ifdef WINDOWSNT
>       /* NT environment variables are case insensitive.  */
>       && ! strnicmp (SSDATA (entry), var, varlen)
>

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

Re: Emacs 25.2, win64, env vars

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 12 Jun 2017 06:40:40 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Thanks Noam.
> Yes, the case is handled for getenv. 
> The problem seems to be with setenv.
> The following is a possible fix.

Do you still see this problem on the current master?  I don't see your
proposed change committed, but I cannot reproduce the problem,
either.  Was this fixed in some other way?

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

2017-07-10 19:08 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Mon, 12 Jun 2017 06:40:40 +0200
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > Thanks Noam.
> > Yes, the case is handled for getenv.
> > The problem seems to be with setenv.
> > The following is a possible fix.
>
> Do you still see this problem on the current master?  I don't see your
> proposed change committed, but I cannot reproduce the problem,
> either.  Was this fixed in some other way?
>

A bit strange, because I just did a 'make bootstrap' on master, and I still
see the problem.

Fabrice

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

Re: Emacs 25.2, win64, env vars

[Noam Postavsky]

On Tue, Jul 11, 2017 at 5:17 AM, Fabrice Popineau
<fabrice.popineau@gmail.com> wrote:
>
> A bit strange, because I just did a 'make bootstrap' on master, and I still
> see the problem.

I can't produce the problem:

(progn
  (princ (format "rev = %s\n" emacs-repository-version))
  (princ (format "1. TEMP = %s\ntemp = %s\n"
                 (getenv "TEMP") (getenv "temp")))
  (setenv "TEMP" "c:/BigTemp/")
  (princ (format "2. TEMP = %s\ntemp = %s\n"
                 (getenv "TEMP") (getenv "temp")))
  (setenv "temp" "c:/LittleTemp/")
  (princ (format "3. TEMP = %s\ntemp = %s\n"
                 (getenv "TEMP") (getenv "temp")))
  nil)

rev = 0bece6c6815cc59e181817a2765a4ea752f34f56
1. TEMP = C:\Users\npostavs\AppData\Local\Temp
temp = C:\Users\npostavs\AppData\Local\Temp
2. TEMP = c:/BigTemp/
temp = c:/BigTemp/
3. TEMP = c:/LittleTemp/
temp = c:/LittleTemp/

Re: Emacs 25.2, win64, env vars

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Tue, 11 Jul 2017 11:17:29 +0200
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <emacs-devel@gnu.org>
> 
>  Do you still see this problem on the current master? I don't see your
>  proposed change committed, but I cannot reproduce the problem,
>  either. Was this fixed in some other way?
> 
> A bit strange, because I just did a 'make bootstrap' on master, and I still see the problem.

I see a possible misunderstanding here.  Your OP included more than
one problematic recipe, so which one are you trying now?

The first recipe you've shown is this:

  (getenv "TEMP")
  "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
  (getenv "temp")
  "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"

  (setenv "TEMP" "c:/Temp/")
  "c:/Temp/"
  (getenv "TEMP")
  "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
  (getenv "temp")
  "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"

Is this still what you see now?  If so, does it mean that after
invoking 'setenv', your process-environment has 2 members which both
start with "TEMP=", but have different values?  Because _this_ is what
I cannot reproduce and frankly don't understand how could it happen.

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

2017-07-11 16:43 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Tue, 11 Jul 2017 11:17:29 +0200
> > Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <
> emacs-devel@gnu.org>
> >
> >  Do you still see this problem on the current master? I don't see your
> >  proposed change committed, but I cannot reproduce the problem,
> >  either. Was this fixed in some other way?
> >
> > A bit strange, because I just did a 'make bootstrap' on master, and I
> still see the problem.
>
> I see a possible misunderstanding here.  Your OP included more than
> one problematic recipe, so which one are you trying now?
>

I didn't intend it to be more than one problematic recipe.
I intended it to be the log of a few forms evaluated in sequence to show
onl oe problem.


>
> The first recipe you've shown is this:
>
>   (getenv "TEMP")
>   "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
>   (getenv "temp")
>   "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
>
>   (setenv "TEMP" "c:/Temp/")
>   "c:/Temp/"
>   (getenv "TEMP")
>   "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
>   (getenv "temp")
>   "C:\\Users\\Fabrice\\AppData\\Roaming\\Local\\Temp"
>
> Is this still what you see now?


Yes.


> If so, does it mean that after
> invoking 'setenv', your process-environment has 2 members which both
> start with "TEMP=", but have different values?  Because _this_ is what
> I cannot reproduce and frankly don't understand how could it happen.
>

And now I understand the reason why you don't see the problem.
I compile emacs from a mingw64 prompt. I have started emacs from the msys2
bash.
This is what messes up the environment.

One one hand, I would say that my proposed fix is harmless and makes sure
case insensitive search is used
for platforms where env vars are supposed to be case insensitive.
On the other hand, the problem is the msys2 bash.

Fabrice

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

Re: Emacs 25.2, win64, env vars

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Tue, 11 Jul 2017 18:24:15 +0200
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <emacs-devel@gnu.org>
> 
>  If so, does it mean that after
>  invoking 'setenv', your process-environment has 2 members which both
>  start with "TEMP=", but have different values? Because _this_ is what
>  I cannot reproduce and frankly don't understand how could it happen.
> 
> And now I understand the reason why you don't see the problem.
> I compile emacs from a mingw64 prompt. I have started emacs from the msys2 bash.
> This is what messes up the environment. 

Can you tell the details of how it "messes up" the environment?

> One one hand, I would say that my proposed fix is harmless and makes sure case insensitive search is used
> for platforms where env vars are supposed to be case insensitive.
> On the other hand, the problem is the msys2 bash.

Maybe we can fix that use case as well, if we understand it well
enough.

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

2017-07-11 18:30 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Tue, 11 Jul 2017 18:24:15 +0200
> > Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <
> emacs-devel@gnu.org>
> >
> >  If so, does it mean that after
> >  invoking 'setenv', your process-environment has 2 members which both
> >  start with "TEMP=", but have different values? Because _this_ is what
> >  I cannot reproduce and frankly don't understand how could it happen.
> >
> > And now I understand the reason why you don't see the problem.
> > I compile emacs from a mingw64 prompt. I have started emacs from the
> msys2 bash.
> > This is what messes up the environment.
>
> Can you tell the details of how it "messes up" the environment?
>

Bash implements a case sensitive environment :

Fabrice@LOBSANG
$ export FOO=BAR

Fabrice@LOBSANG
$ export foo=baz

Fabrice@LOBSANG
$ echo $FOO
BAR

Fabrice@LOBSANG
$ echo $foo
baz

Emacs is built as a mingw64 app, not an msys app.
So it should behave as any native Windows app, wether you run it from bash
or not.
At least, that is what I would expect.
So in this case, the environment variables should be considered case
insensitive.
But emacs will inherit the env vars from bash, and arguably, they are case
sensitive.

Another option is to make emacs inherit the variables from the desktop, not
from the shell (or cmd) it is started from.
That would make sense at least for a GUI emacs. But that is less flexible.

Fabrice

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

Re: Emacs 25.2, win64, env vars

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Tue, 11 Jul 2017 18:24:15 +0200
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <emacs-devel@gnu.org>
> 
> And now I understand the reason why you don't see the problem.
> I compile emacs from a mingw64 prompt. I have started emacs from the msys2 bash.
> This is what messes up the environment. 
> 
> One one hand, I would say that my proposed fix is harmless and makes sure case insensitive search is used
> for platforms where env vars are supposed to be case insensitive.
> On the other hand, the problem is the msys2 bash.

Ping!  If we want to fix this problem, please tell the details about
how the MSYS2 Bash causes it.  If not, let's decide that we don't
want to fix it.

Thanks.

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

2017-07-22 9:07 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Tue, 11 Jul 2017 18:24:15 +0200
> > Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <
> emacs-devel@gnu.org>
> >
> > And now I understand the reason why you don't see the problem.
> > I compile emacs from a mingw64 prompt. I have started emacs from the
> msys2 bash.
> > This is what messes up the environment.
> >
> > One one hand, I would say that my proposed fix is harmless and makes
> sure case insensitive search is used
> > for platforms where env vars are supposed to be case insensitive.
> > On the other hand, the problem is the msys2 bash.
>
> Ping!  If we want to fix this problem, please tell the details about
> how the MSYS2 Bash causes it.  If not, let's decide that we don't
> want to fix it.
>

I thought my previous answer was pretty explicit.

MSYS2 bash implements a case sensitive environment, which is different from
the native win32 environment.
If emacs is started from the bash command line, it inherits this
environment.
However this is rather unexpected.
It is hard to tell if a GUI emacs has been started from bash, cmd or from
the desktop.
So the fact that the behaviour is changing accorting to the starting
environment
is annoying.
IMHO and according to the least surprise principle, win32 emacs should
behave as a native app, and not follow this kind of fancy unixy thing.
I would even recommend that emacs inherits from the desktop environment,
not the environment from the shell that was used to run emacs.

Regards,

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

Re: Emacs 25.2, win64, env vars

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 22 Jul 2017 22:02:03 +0200
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <emacs-devel@gnu.org>
> 
>  Ping! If we want to fix this problem, please tell the details about
>  how the MSYS2 Bash causes it. If not, let's decide that we don't
>  want to fix it.
> 
> I thought my previous answer was pretty explicit.

Sorry, it's probably my misunderstanding.

> MSYS2 bash implements a case sensitive environment, which is different from the native win32 environment.
> If emacs is started from the bash command line, it inherits this environment.

So you are saying that MSYS holds two separate environment variables,
one called "temp", the other "TEMP"?  If so, what do native Windows
programs started from such a shell get in their environment?  The
upper-case one? the first one in the order? both? something else?

> I would even recommend that emacs inherits from the desktop environment, not the environment from the
> shell that was used to run emacs.

I expect this to break quite a few legitimate use cases.

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

2017-07-23 16:48 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sat, 22 Jul 2017 22:02:03 +0200
> > Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <
> emacs-devel@gnu.org>
> >
> >  Ping! If we want to fix this problem, please tell the details about
> >  how the MSYS2 Bash causes it. If not, let's decide that we don't
> >  want to fix it.
> >
> > I thought my previous answer was pretty explicit.
>
> Sorry, it's probably my misunderstanding.
>
> > MSYS2 bash implements a case sensitive environment, which is different
> from the native win32 environment.
> > If emacs is started from the bash command line, it inherits this
> environment.
>
> So you are saying that MSYS holds two separate environment variables,
> one called "temp", the other "TEMP"?  If so, what do native Windows
> programs started from such a shell get in their environment?  The
> upper-case one? the first one in the order? both? something else?
>

 Both GetEnvironmentVariable) and getenv() return :

TEMP=C:\MSys64\tmpy
temp=C:\MSys64\tmp

And from the shell :

$ echo $TEMP
/tmp

$ echo $temp
C:\Users\Fabrice\AppData\Roaming\Local\Temp

So they return the win32 path from the value of the upper case variable.


>
> > I would even recommend that emacs inherits from the desktop environment,
> not the environment from the
> > shell that was used to run emacs.
>
> I expect this to break quite a few legitimate use cases.
>

Maybe (albeit I couldn't name them).

My opinion (but I may well be alone)  is that Emacs/win32 fiddles too much
with those unix-like environments.
This works most of the time, but it also sometimes creates surprising
situations.


Fabrice

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

Re: Emacs 25.2, win64, env vars

[Noam Postavsky]

On Mon, Jul 24, 2017 at 4:34 PM, Fabrice Popineau
<fabrice.popineau@gmail.com> wrote:
>> > I would even recommend that emacs inherits from the desktop environment,
>> > not the environment from the
>> > shell that was used to run emacs.
>>
>> I expect this to break quite a few legitimate use cases.
>
>
> Maybe (albeit I couldn't name them).

One (somewhat hypothetical) example would be a bat file which sets up
a portable HOME before starting emacs.

Personally, I find it useful for testing to do 'set
HOME=C:/tmp/whatever' in certain situations. Having to set the global
desktop environment for this would be a pain.

> My opinion (but I may well be alone)  is that Emacs/win32 fiddles too much
> with those unix-like environments.
> This works most of the time, but it also sometimes creates surprising
> situations.

Using the "desktop environment" in preference to the shell environment
would create more surprise for me. Do any other applications do this?

Re: Emacs 25.2, win64, env vars

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 24 Jul 2017 22:34:20 +0200
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <emacs-devel@gnu.org>
> 
>  So you are saying that MSYS holds two separate environment variables,
>  one called "temp", the other "TEMP"? If so, what do native Windows
>  programs started from such a shell get in their environment? The
>  upper-case one? the first one in the order? both? something else?
> 
> Both GetEnvironmentVariable) and getenv() return :
> 
> TEMP=C:\MSys64\tmpy
> temp=C:\MSys64\tmp
> 
> And from the shell :
> 
> $ echo $TEMP
> /tmp
> 
> $ echo $temp
> C:\Users\Fabrice\AppData\Roaming\Local\Temp
> 
> So they return the win32 path from the value of the upper case variable.

Maybe we could remove the lower-case variant at startup, so that it
won't get in the way of programs Emacs invokes?  Or could that break
some use cases for people who also set their shell in Emacs to the
MSYS shell?

> My opinion (but I may well be alone) is that Emacs/win32 fiddles too much with those unix-like environments.
> This works most of the time, but it also sometimes creates surprising situations.

Environment variables are not limited to Unix, so I'm not sure why you
think it's Unix-like.

Re: Emacs 25.2, win64, env vars

[Fabrice Popineau]

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

2017-07-25 16:16 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Mon, 24 Jul 2017 22:34:20 +0200
> > Cc: Noam Postavsky <npostavs@users.sourceforge.net>, Emacs developers <
> emacs-devel@gnu.org>
> >
> >  So you are saying that MSYS holds two separate environment variables,
> >  one called "temp", the other "TEMP"? If so, what do native Windows
> >  programs started from such a shell get in their environment? The
> >  upper-case one? the first one in the order? both? something else?
> >
> > Both GetEnvironmentVariable) and getenv() return :
> >
> > TEMP=C:\MSys64\tmpy
> > temp=C:\MSys64\tmp
> >
> > And from the shell :
> >
> > $ echo $TEMP
> > /tmp
> >
> > $ echo $temp
> > C:\Users\Fabrice\AppData\Roaming\Local\Temp
> >
> > So they return the win32 path from the value of the upper case variable.
>
> Maybe we could remove the lower-case variant at startup, so that it
> won't get in the way of programs Emacs invokes?  Or could that break
> some use cases for people who also set their shell in Emacs to the
> MSYS shell?
>

I think for this specific issue (if only it is an issue), there are only 2
options :

1 - do nothing. Possibly find a place to document the fact that under
Windows, emacs will inherit variables from the starting shell and that some
shells
may provide case sensitive environment variables.
2 - remove the case insensitive comparison for WINDOWSNT in
getenv_internal_1 and replace it with a case sensitive one because some
shells may
provide case sensitive environment variables . This will result in handling
case sensitive environment variables even under Windows. I guess it would
need some testing to ensure
everything works as expected, under MSYS2 or Cygwin.
3 - apply the fix I offered (or another equivalent one ?)  because it makes
the handling of environment variables case symetrical for setenv and
getenv, and both are case insensitive.

I think option 1 is not an option because the scenario I have shown
initially appears as inconsistant.
So it leaves option 2 and 3, depending on wether you want  case sensitive
or case insensitive environment variables.



> > My opinion (but I may well be alone) is that Emacs/win32 fiddles too
> much with those unix-like environments.
> > This works most of the time, but it also sometimes creates surprising
> situations.
>
> Environment variables are not limited to Unix, so I'm not sure why you
> think it's Unix-like.
>

I was speaking more generally. I'll try to find time to gather the various
places (mostly elpa packages) I have found where
Emacs/win32 tries to  behave as Emacs/unix but should avoid it. Sometimes
because the wrong path
is parsed (mixture between paths syntax), sometimes because when sh.exe is
found, some Unix machinery
starts but can't complete. That is another story.

Fabrice

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

Re: Emacs 25.2, win64, env vars

[Stefan Monnier]

> 1 - do nothing. Possibly find a place to document the fact that under
> Windows, emacs will inherit variables from the starting shell and that some
> shells
> may provide case sensitive environment variables.
> 2 - remove the case insensitive comparison for WINDOWSNT in
> getenv_internal_1 and replace it with a case sensitive one because some
> shells may
> provide case sensitive environment variables . This will result in handling
> case sensitive environment variables even under Windows. I guess it would
> need some testing to ensure
> everything works as expected, under MSYS2 or Cygwin.
> 3 - apply the fix I offered (or another equivalent one ?)  because it makes
> the handling of environment variables case symetrical for setenv and
> getenv, and both are case insensitive.

There's also

4 - first lookup case-sensitively, then if that fails, lookup with
    case-fold.

Whichever behavior is chosen, there's a somewhat orthogonal issue that
needs to be addressed: detect the ambiguity and warn the user when it occurs.


        Stefan

Re: Emacs 25.2, win64, env vars

[Óscar Fuentes]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> 3 - apply the fix I offered (or another equivalent one ?)  because it makes
> the handling of environment variables case symetrical for setenv and
> getenv, and both are case insensitive.

+1

I was affected by this issue. Two hours lost trying to figure out what
the problem was an how to work around it.

There are bug reports all around about other cross-platform projects
which found the same problem. Python, for instance, uppercases all
environment variables on Windows.

Emacs should follow the conventions of the host OS.