Re: [PATCH 1/2] submodule: fix confusing variable name

[Mark Levedahl <mlevedahl@gmail.com>]

On 08/08/2013 01:44 PM, Ramsay Jones wrote:
> 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