On 2023-06-01 at 22:21:05, Priedhorsky, Reid wrote:
> Hello,
> 
> I may have found a bug in Git. It seems that if (1) multiple git(1) are installed on the system, (2) one is in the shell’s default path (i.e., used if $PATH is unset, not the default value of $PATH), and (3) the desired git(1) is at a different path, then subprocesses of the desired git(1) invoke the undesired git(1) instead.
> 
> $PATH unset is indeed a pathological situation; one of our own bugs in our software that calls git(1) inappropriately cleared it. However, in my view it’s surprising enough to be a usability bug. I would expect git(1) to call itself for subprocesses regardless of the environment.

I don't believe this is a bug in Git, but rather a behaviour of your
operating system kernel.  If you don't set PATH, then when Git does an
exec, the kernel or libc supplies a default PATH value.  Traditionally
this includes /bin and /usr/bin, and on some systems, it used to contain
the current working directory, which has typically been removed for
security.

It isn't possibly to portably determine that path that was used to exec
the current binary, so Git doesn't try to do so, and it assumes that you
set PATH appropriately.  In fact, on some systems, you can use fexecve
to execute file descriptors pointing to files that have been unlinked,
so in general, it's not possible to determine which binary to use
without the PATH.

I'm not aware of any other major programs which do this in a better or
more useful way, so I don't think there's anything to change here in
Git.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA