From: Ramsay Jones <ramsay@ramsay1•demon.co.uk>
To: Junio C Hamano <gitster@pobox•com>
Cc: bwalton@artsci•utoronto.ca, Johannes Sixt <j6t@kdbg•org>,
Jens.Lehmann@web•de, avarab@gmail•com,
GIT Mailing-list <git@vger•kernel.org>
Subject: Re: [PATCH] git-submodule.sh: Don't use $path variable in eval_gettext string
Date: Tue, 24 Apr 2012 18:32:35 +0100 [thread overview]
Message-ID: <4F96E3B3.2080408@ramsay1.demon.co.uk> (raw)
In-Reply-To: <7v4nsgk3os.fsf@alter.siamese.dyndns.org>
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
prev parent reply other threads:[~2012-04-24 17:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 18:00 [PATCH] git-submodule.sh: Don't use $path variable in eval_gettext string Ramsay Jones
2012-04-18 11:05 ` Jens Lehmann
2012-04-18 18:11 ` Johannes Sixt
2012-04-18 20:06 ` Ramsay Jones
2012-04-18 23:42 ` Junio C Hamano
2012-04-24 17:32 ` Ramsay Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F96E3B3.2080408@ramsay1.demon.co.uk \
--to=ramsay@ramsay1$(echo .)demon.co.uk \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=avarab@gmail$(echo .)com \
--cc=bwalton@artsci$(echo .)utoronto.ca \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=j6t@kdbg$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox