Re: [PATCH] var(win32): do report the GIT_SHELL_PATH that is actually used

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 8, 2024, 23:55 UTC
Message-ID: <xmqqr0c3h21e.fsf@gitster.g>
In-Reply-To: <Zox48sVp-PybvLxi@tapette.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 8 quoted lines

>> The "look on the %PATH%" strategy does not make any sense as an
>> implementation for getting GIT_SHELL_PATH, which answers "what is
>> the shell this instanciation of Git was built to work with?", at
>> least to me.  Maybe I am missing some knowledge on limitations on
>> Windows and Git for Windows why it is done that way.
>
> Well, it may be that that's the approach that Git for Windows takes to
> look up the shell.  (I don't know for certain.)

Show 5 quoted lines

> If that _is_ what it does, then that's absolutely the value we
> want because we want to use whatever shell Git for Windows uses.
> I will say it's a risky approach because it could well also find a
> Cygwin or MINGW shell (or, if it were called bash, WSL), but we
> really want whatever Git for Windows does here.

Yeah, absolutely it is risky unless it is doing the "we are relocatable, so where is the 'sh' _we_ installed?", which is what I would expect GIT_SHELL_PATH to be.

> 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).

Thanks.