Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
- From
Andreas Ericsson <ae@op5.se>
- Date
- Jan 11, 2006, 00:06 UTC
- Message-ID
- <43C44C12.3050609@op5.se>
- In-Reply-To
- <1136924980.11717.603.camel@brick.watson.ibm.com>
Michal Ostrowski wrote:
Show 15 quoted lines
> On Tue, 2006-01-10 at 11:47 -0800, Junio C Hamano wrote: > >> >>>Good point. Perhaps we should only prepend to path when the directory >>>isn't already in $PATH, or append rather than prepend. >> >>I think appending not prepending would stop letting me say >> >> $ GIT_EXEC_PATH=/usr/libexec/git-core/0.99.9k git foo >> >>to try out older version, if I have more recent git in my PATH. >>But I agree with Michal it is not nice to affect invocations of >>"diff" (and things spawned from hooks, which would inherit PATH >>from receive-pack). >>
So how about prepending only when the directory isn't already in the PATH? That can be done with a two-line patch to git.c only.
It will break the "diff in another dir" scenario in the highly unlikely event that the other diff is located in the same dir as the git suite, isn't supposed to be used, and the directory in question isn't in $PATH already. People who have such a setup will be too ashamed to admit it, so we're not likely to be blamed for it either. ;)
Show 11 quoted lines
>>
>
>
> How about searching for executables in the following places, and in this
> order:
>
> 1. --exec-path setting, if any
> 2. GIT_EXEC_PATH env var, if set
> 3. PATH (never modified)
> 4. Value of ${bindir} at build time
> This is more or less what's done today, with the exception that $PATH isn't searched and it throws an error immediately no matter where exec_path (the git.c variable) came from.
Adding $PATH to the search-pattern would be a simple matter of falling back to execvp() if execve(), but then we could end up with running programs from a different release while the user thinks he/she's specifically running 1.0.3... Tricky problem, really.
Show 6 quoted lines
> > Secondly, the shell scripts as is cannot utilize this search order as > long as they don't religiously use the git potty internally. If we were > to "sed -e 's/git-/git /g' -i git*.sh" (grotesquely simplified of > course) then they would. >
I think this has been done, but as it happened to be convenient. I'd prefer if the git potty could keep prepending the GIT_EXEC_PATH to the path, really. We're bound to run into setup-related problems otherwise, such as;
Alice writes a script that works fine for her and her friends, so she shares it freely with Bob and whoever else might be listening. Bob's git-tools aren't in the $PATH but he keeps the potty handy at all times. He can't always run it through the potty because in some code-paths Alice's script uses git-tools without going through the potty. Bob thinks Alice puts entropy in her programs on purpose, so Alice flees, sobbing and shaking in anger and betrayed trust. The two never speak again.
Luckily, Bruce Schneier shows up and saves the day.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231