[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 25.2, win64, env vars

From: Fabrice Popineau
Subject: Re: Emacs 25.2, win64, env vars
Date: Thu, 27 Jul 2017 18:35:32 +0200

2017-07-25 16:16 GMT+02:00 Eli Zaretskii <address@hidden>:
> From: Fabrice Popineau <address@hidden>
> Date: Mon, 24 Jul 2017 22:34:20 +0200
> Cc: Noam Postavsky <address@hiddennet>, Emacs developers <address@hidden>
>  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]