From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: Emacs 25.2, win64, env vars Date: Thu, 27 Jul 2017 18:35:32 +0200 Message-ID: References: <83r2xoi5i5.fsf@gnu.org> <837ezfjaoy.fsf@gnu.org> <83inil9cg2.fsf@gnu.org> <83eft78b05.fsf@gnu.org> <83d18o7ga3.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11472a8670a71005554f28ee" X-Trace: blaine.gmane.org 1501173368 9533 195.159.176.226 (27 Jul 2017 16:36:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Jul 2017 16:36:08 +0000 (UTC) Cc: Emacs developers , Noam Postavsky To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 27 18:36:02 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dallY-00026s-1H for ged-emacs-devel@m.gmane.org; Thu, 27 Jul 2017 18:36:00 +0200 Original-Received: from localhost ([::1]:44008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dalld-0008Ha-RP for ged-emacs-devel@m.gmane.org; Thu, 27 Jul 2017 12:36:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dallW-0008HE-M4 for emacs-devel@gnu.org; Thu, 27 Jul 2017 12:35:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dallV-0003Ke-Cd for emacs-devel@gnu.org; Thu, 27 Jul 2017 12:35:58 -0400 Original-Received: from mail-qk0-x231.google.com ([2607:f8b0:400d:c09::231]:35738) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dallT-0003Hr-6p; Thu, 27 Jul 2017 12:35:55 -0400 Original-Received: by mail-qk0-x231.google.com with SMTP id d145so99463923qkc.2; Thu, 27 Jul 2017 09:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIxNyVLgni9NPHKq9/m4jrFqryFOOGn+2ByBiPtBtf4=; b=VpX6q2u45NQ3O85CTsbcaWvw7MgGSOYovkCiZnp4B8IHEZnzVY/WDR36bs1QWzp/np jYOMMEc2N3iiSUpaRZGTn9DcSEaXFvf0vOqEXhcRY8ZBZMGLLKdRGp/WjocqxlT+pBRC byTqJD04z42Uwxr8oZvMHyRsos364X0W8ZKCLPqWsPYTjKhMeJDGojC20qkQMTefjitV o8xbU6CFHP1qaLqErQK+GwKHUFQI3mYp/QYMrr1wSNR4MeQgBAdvW4tH+X1HldwLtSwF 50++levZLdLga1ohfPzkigzt3KihBYh5eranMgdGXS+rZAIgbIJXJwJsI8L684U83voz OIWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIxNyVLgni9NPHKq9/m4jrFqryFOOGn+2ByBiPtBtf4=; b=IIQI/Op/BYZocME5g+y097ZjbNyuoMb7HnPTGaYnn7GLzJI9WK2iUjmMtoVfcAihXW lmTj1fVi3suy1Fe82/CK42wZ9bpG1BW8AF/pr0h6TQsTRHAPtE+R9h/1fkrO+aUomUbR g62qQwGKAsZnH/Ca19QsZ0HQkorDP1VStylRHeBPHWw42HzEsn76Cqc7vQA08pexJTXk 4c3ZlUs0jO8FH1slJjImttm4+e80iCVz4vo2PNtdnbbu9OPrONFE1tq3YEUTheEkAsav URgpOcJrkCaXqUUDnLj/LbuSXychTVp5VQwAC1LWgjrnLI7kNr1OvD3gcrxmc743h3P4 EWjg== X-Gm-Message-State: AIVw110JIYLhD1ZlCnJVsT63IX0xqfVbDD0S2yT8qvlHYqWtBOCY8JDD XJYN5LtGoV4Galj4uMUnOnJydUPiog== X-Received: by 10.55.55.7 with SMTP id e7mr6353697qka.294.1501173352800; Thu, 27 Jul 2017 09:35:52 -0700 (PDT) Original-Received: by 10.140.82.21 with HTTP; Thu, 27 Jul 2017 09:35:32 -0700 (PDT) In-Reply-To: <83d18o7ga3.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217080 Archived-At: --001a11472a8670a71005554f28ee Content-Type: text/plain; charset="UTF-8" 2017-07-25 16:16 GMT+02:00 Eli Zaretskii : > > From: Fabrice Popineau > > Date: Mon, 24 Jul 2017 22:34:20 +0200 > > Cc: Noam Postavsky , 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 --001a11472a8670a71005554f28ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 deve= lopers <emacs-devel@gnu.org&g= t;
>
>=C2=A0 So you are saying that MSYS holds two se= parate environment variables,
>=C2=A0 one called "temp", the other "TEMP"? If so, = what do native Windows
>=C2=A0 programs started from such a shell get in their environment? The=
>=C2=A0 upper-case one? the first one in the order? both? something else= ?
>
> Both GetEnvironmentVariable) and getenv() return :
>
> TEMP=3DC:\MSys64\tmpy
> temp=3DC:\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 variabl= e.

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

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

1 - do nothing. Possibly find a place to document the fact that und= er Windows, emacs will inherit variables from the starting shell and that s= ome shells=C2=A0
may provide case sensitive environment variables= .
2 - remove the case insensitive comparison for WINDOWSNT in get= env_internal_1 and replace it with a case sensitive one because some shells= may
provide case sensitive environment variables . This will res= ult in handling case sensitive environment variables even under Windows. I = guess it would need some testing to ensure
everything works as ex= pected, under MSYS2 or Cygwin.
3 - apply the fix I offered (or an= other equivalent one ?) =C2=A0because it makes the handling of environment = variables case symetrical for setenv and getenv, and both are case insensit= ive.

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


=

> My opinion (but I may well be alone) is that Emacs/win32 fiddles too m= uch 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 w= hy 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=C2=A0
Ema= cs/win32 tries to =C2=A0behave 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 ma= chinery
starts but can't complete. That= is another story.

Fabrice

--001a11472a8670a71005554f28ee--