Re: [PATCH] git-submodule.sh: Don't use $path variable in eval_gettext string

[Ramsay Jones <ramsay@ramsay1.demon.co.uk>]

Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> 
>> As an alternative, we finesse the problem by renaming the $path
>> variable to $sm_path (submodule path). This fixes the problem on
>> MinGW along with all test failures on cygwin (t7400.{7,32,34},
>> t7406.3 and t7407.{2,6}). We note that the foreach subcommand
>> provides $path to user scripts (ie it is part of the API), so we
>> can't simply rename it to $sm_path.
> 
> Which might mean that foreach is unusable on systems whose environment
> variables are case insensitive, as whatever command spawned by foreach
> has its $PATH clobberred.  

[sorry for the late reply; I've been away from email for nearly a week.]

No, the foreach command is (mostly) fine; given the fact that the user
script is eval-ed in a context in which $path is not exported. The reason
for the 'mostly' is simply that the user could shoot himself in the
foot by export-ing $path in their script, so that something like:

    $ git submodule foreach 'export path; echo $path `git rev-parse HEAD`'

will indeed fail (ie git rev-parse will not execute).

How likely is this to happen? I suspect it would be somewhat rare.

Hmm, does it deserve a note in the docs?

>                            It is not a regression to them, so it is not
> urgent to address it, but going forward, perhaps we can encourage users
> of _all_ platforms to use $sm_path for portability?

Maybe, but I don't have strong feelings either way. Using $sm_path rather
than $path would, of course, eliminate even the above (very unlikely)
problem ...

ATB,
Ramsay Jones