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

From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Date: Apr 24, 2012, 17:32 UTC
Message-ID: <4F96E3B3.2080408@ramsay1.demon.co.uk>
In-Reply-To: <7v4nsgk3os.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 12 quoted lines

> 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