Re: [PATCH 1/2] submodule: fix confusing variable name
- From
Mark Levedahl <mlevedahl@gmail.com>
- Date
- Aug 11, 2013, 19:53 UTC
- Message-ID
- <5207EBD2.6050802@gmail.com>
- In-Reply-To
- <5203D8F6.2020102@ramsay1.demon.co.uk>
On 08/08/2013 01:44 PM, Ramsay Jones wrote:
Show 19 quoted lines
> Fredrik Gustafsson wrote: >> On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote: >>> But we'll have to use sm_path here (like everywhere else in the >>> submodule script), because we'll run into problems under Windows >>> otherwise (see 64394e3ae9 for details). Apart from that the patch >>> is fine. >> >> We're still using path= in the foreach-script. Or rather, we're setting >> it. From what I can see and from the commit message 64394e3ae9 it could >> possible be a problem. > > Please do not use a $path variable in any script intended to be run on > windows; those poor souls who would otherwise have to fix the bugs will > thank you! :-D > > Actually, it's not so much the use of a $path variable, rather the act > of _exporting_ such a variable that causes the problem. (Which is why > using $path with eval_gettext[ln] is such a problem, of course.) >
Please note that especially in this case, Cygwin != Windows. Cygwin allows $path, $Path, $PATH, etc., to all coexist and be accessed case sensitively. Exporting $path causes no problem, either. Should the eval invoke a Windows program, $PATH is converted to Windows format and exported, the other case-sensitive variants of path remain in the environment and can be accessed by any program implementing case-sensitive lookup as well. Not sure what will happen with case-insensitive lookups, but a quick test showed that cmd.exe is not bothered by $path given $PATH exists.
Mark