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