git.vger.kernel.org archive mirror
 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: Tue, 09 Jul 2024 09:31:48 -0700	[thread overview]
Message-ID: <xmqqy16afrwr.fsf@gitster.g> (raw)
In-Reply-To: <ZoyDlrcmyXUX_dki@tapette.crustytoothpaste.net> (brian m. carlson's message of "Tue, 9 Jul 2024 00:25:58 +0000")

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

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

Besides, perl and wish are not part of Git.  The same thing can be
said that shell is not part of Git.  

So stepping back and thinking why we have "git var GIT_SHELL_PATH",
what should it mean to begin with?  It is obviously not to tell
where we installed the thing as a part of "Git" suite, even though
Git for Windows installer may let users install the shell and other
stuff (similar to how "apt" lets users install package on Debian
derived systems).

Hence, I can accept that "git var GIT_SHELL_PATH" is not (and does
not have to be) about where we installed what we shipped.  It is
where we use the shell from (i.e., when we need "sh", we use that
shell).

   The documentation for GIT_SHELL_PATH is already good.  Sorry for
   my earlier confusion---I should have looked at it first.  It says
   it is not about what we ship, but what we use when we need to
   shell out.

I am OK with GIT_SHELL_PATH computed differently depending on the
platform, as different platform apparently use different mechanism
to decide which shell to spawn.  On POSIX systems, it is the one we
compiled to use, while on Windows it is the one that happens to be
on the end-user's PATH.

But then the comment I made in my earlier review still stands that
such a platform dependent logic should be implemented a bit more
cleanly than the posted patch.

"Which shell do we use at runtime" should influence a lot of what
the things in run-command.c do, so perhaps

 - we remove builtin/var.c:shell_path()

 - We create run-command.c:git_shell_path() immediately above
   run-command.c:prepare_shell_cmd().  We will add conditional
   compilation there (i.e. #ifdef GIT_WINDOWS_NATIVE).  The default
   implementation is to return SHELL_PATH, and on Windows it looks
   for "sh" on %PATH%.

 - The entry for GIT_SHELL_PATH in builtin/var.c:git_vars[] should
   be updated to point at git_shell_path() in run-command.c

 - Near the beginning of run-command.c:prepare_shell_cmd(), there is
   a conditional compilation.  If we can remove it by using
   git_shell_path(), that would be a nice bonus.

would give us a good approach for implementation?

Thanks.

  reply	other threads:[~2024-07-09 16:32 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
2024-07-09  0:25       ` brian m. carlson
2024-07-09 16:31         ` Junio C Hamano [this message]
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=xmqqy16afrwr.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).