On 2024-07-08 at 23:55:25, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > That's because external users who rely on Git for Windows to furnish a > > POSIX shell will want to know the path, and this variable is the best > > way to do that (and the reason I added it). > > If Git for Windows furnishes programs other than POSIX shell, paths > to which external users would also want to learn, what happens? > GIT_PERL_PATH, GIT_WISH_PATH, etc.? Locate them on PATH themselves > shouldn't be rocket science (and instead of locating, just spawning > them themselves would be even easier, I would presume). In my experience, they have not always been on PATH. It may be that they are now, which is fantastic, but I seem to remember that at some point bash.exe and git.exe were on PATH, but sh.exe and other commands were not. (There's also a different path under Git Bash than the regular Windows PATH.) You might say, "Well, why not use bash.exe?" and that works great until you realize that there's also a bash.exe that is part of WSL and will attempt to spawn WSL for you. However, that doesn't always work, because sometimes WSL isn't installed or is disabled or broken, and so the operation fails with an error message. Also, users will typically have wanted Git for Windows's bash and not a Linux environment's bash, since the two environments will typically have different software available. Why not add Perl or Wish or something else? Because once you have the Git for Windows sh, you can use a fixed Unix path to look them up and get a canonical Windows path with cygpath -w. Thus, this is just the minimal bootstrapping functionality to get that information. Of course, on Unix, there can still be multiple Perl implementations, but you're typically either going to build against one in particular, which may or may not be what Git was built against, or you're going to use /usr/bin/env and choose whatever's first in PATH. In that case, it's very unlikely that anyone cares what version of Perl Git actually uses. The only major benefit of using Git's shell on Unix is that you know it supports POSIX functionality (which /bin/sh does not on some proprietary Unices) and it also supports local, which may be convenient for scripting. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
