All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	 Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] var(win32): do report the GIT_SHELL_PATH that is actually used
Date: Mon, 08 Jul 2024 16:55:25 -0700	[thread overview]
Message-ID: <xmqqr0c3h21e.fsf@gitster.g> (raw)
In-Reply-To: <Zox48sVp-PybvLxi@tapette.crustytoothpaste.net> (brian m. carlson's message of "Mon, 8 Jul 2024 23:40:34 +0000")

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

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

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


  reply	other threads:[~2024-07-08 23:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-08 13:02 [PATCH] var(win32): do report the GIT_SHELL_PATH that is actually used Johannes Schindelin via GitGitGadget
2024-07-08 18:54 ` Junio C Hamano
2024-07-08 23:40   ` brian m. carlson
2024-07-08 23:55     ` Junio C Hamano [this message]
2024-07-09  0:25       ` brian m. carlson
2024-07-09 16:31         ` Junio C Hamano
2024-07-09 13:53     ` Phillip Wood
2024-07-08 19:03 ` Junio C Hamano
2024-07-09  8:55 ` Phillip Wood
2024-07-11 12:03   ` Johannes Schindelin
2024-07-17 14:55     ` phillip.wood123
2024-07-11 23:11 ` [PATCH v2 0/7] " Johannes Schindelin via GitGitGadget
2024-07-11 23:11   ` [PATCH v2 1/7] run-command: refactor getting the Unix shell path into its own function Johannes Schindelin via GitGitGadget
2024-07-11 23:11   ` [PATCH v2 2/7] strvec: declare the `strvec_push_nodup()` function globally Johannes Schindelin via GitGitGadget
2024-07-11 23:11   ` [PATCH v2 3/7] win32: override `fspathcmp()` with a directory separator-aware version Johannes Schindelin via GitGitGadget
2024-07-12 13:46     ` Phillip Wood
2024-07-11 23:11   ` [PATCH v2 4/7] mingw(is_msys2_sh): handle forward slashes in the `sh.exe` path, too Johannes Schindelin via GitGitGadget
2024-07-12 13:49     ` Phillip Wood
2024-07-11 23:11   ` [PATCH v2 5/7] run-command(win32): resolve the path to the Unix shell early Johannes Schindelin via GitGitGadget
2024-07-11 23:11   ` [PATCH v2 6/7] run-command: declare the `git_shell_path()` function globally Johannes Schindelin via GitGitGadget
2024-07-11 23:11   ` [PATCH v2 7/7] var(win32): do report the GIT_SHELL_PATH that is actually used Johannes Schindelin via GitGitGadget
2024-07-12 15:35     ` Junio C Hamano
2024-07-12 13:51   ` [PATCH v2 0/7] " Phillip Wood
2024-07-12 22:16     ` Junio C Hamano
2024-07-13 21:08   ` [PATCH v3 " Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 1/7] run-command: refactor getting the Unix shell path into its own function Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 2/7] strvec: declare the `strvec_push_nodup()` function globally Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 3/7] win32: override `fspathcmp()` with a directory separator-aware version Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 4/7] mingw(is_msys2_sh): handle forward slashes in the `sh.exe` path, too Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 5/7] run-command(win32): resolve the path to the Unix shell early Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 6/7] run-command: declare the `git_shell_path()` function globally Johannes Schindelin via GitGitGadget
2024-07-13 21:08     ` [PATCH v3 7/7] var(win32): do report the GIT_SHELL_PATH that is actually used Johannes Schindelin via GitGitGadget
2024-07-17 14:51     ` [PATCH v3 0/7] " Phillip Wood
2024-07-17 22:47     ` brian m. carlson
2024-07-17 22:51       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr0c3h21e.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.