Thread (10 messages) flat view 10 messages, 4 authors, 2016-06-15

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

From: Andreas Ericsson <hidden>
Date: 2016-06-15 22:42:16

Possibly related (same subject, not in this thread)

Michal Ostrowski wrote:
On Tue, 2006-01-10 at 11:47 -0800, Junio C Hamano wrote:
quoted
quoted
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. ;)
quoted

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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help