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
Attachment:
signature.asc
Description: PGP signature
