Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s

From: Junio C Hamano <junkio@cox.net>
Date: Jan 10, 2006, 19:47 UTC
Message-ID: <7vzmm36f1x.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1136910406.11717.579.camel@brick.watson.ibm.com>

Michal Ostrowski <mostrows@watson.ibm.com> writes:

Show 9 quoted lines

> One could make all the scripts depend on GIT_EXEC_PATH instead of PATH.
> At build time one could generate wrapper functions in git-sh-setup:
>
> function git-foo () {
> 	$(GIT_EXEC_PATH)/git-foo $*;
> }
>
> Presuming that all scripts include git-sh-setup, no other shell script
> changes would be needed.

Is "git-foo" a valid name to define shell function as?

> My shell's rc-file doesn't get invoked when using ssh as a transport;
> that's part of the problem.

Not any rc, or are you bitten by bash/ssh misfeature that noninteractive sessions do not start with .bash_profile?

Show 5 quoted lines

>> > Once you have that implemented, we can have a separate discussion of how
>> > the executable is to be found; 
>> >  - should we use PATH?
>> >  - should we change PATH?
>> >  - should we always exec using an absolute file name? (my preference)

The goal here is to make sure we exec the program from the same release (unless user overrides it with GIT_EXEC_PATH to say "I want to try 0.99.9k, not the latest one"), but how? The last one feels the most correct way if done right.

> git programs exec other git programs, but they also exec non-git
> programs.  I think it is not appropriate to change PATH (via
> prepend_to_path) because this may result in unexpected behavior when
> exec'ing non-git programs:

This is a valid concern.