Allow specifying at runtime which POSIX shell to use #3301
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dantez11
approved these changes
Jul 2, 2021
dantez11
approved these changes
Jul 2, 2021
Right now, the compiled-in default is used always, which can be overridden at compile time via the `SHELL_PATH` variable. However, in Git for Windows' context, there is a scenario where this is not good enough: the BusyBox flavor of MinGit wants to use BusyBox' `ash` instead. To allow for that, let's introduce a new config variable: `core.shell`. Its value is expected to be the absolute path to a valid, working POSIX shell. This shell will be then used by `git.exe` whenever it needs to execute something via shell, such as moderately complex aliases. And it is not only Git that is expected to use that `ash`, it is also OpenSSH (e.g. when running any configured `ProxyCommand`): programs spawned from `git.exe` may need to run a shell and look at the environment variable `SHELL` for that. Therefore, let's set that, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, we have to emulate that Linux/Unix/macOS feature where a file starting with a `#!` line and being marked as executable is run as a script through the interpreter specified by said `#!` line. Traditionally, we ignore the actual path specified in that line because it will be a Unix-style path anyway, something that `git.exe` is not even supposed to understand. We then go on to look up the actual path of the interpreter by iterating over the components in the environment variable `PATH`. Let's special-case `sh` in that scenario when the config setting `core.shell` exists: in this case, we want to use it instead. This allows us to configure BusyBox' `ash` to be used for all of the shell scripting needs of the BusyBox flavor of MinGit. While at it, assume that any shell configured via `core.shell` is _not_ an MSYS2 shell, i.e. that we should use regular Win32 command-line quoting, not MSYS2/Cygwin one. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We already have the
SHELL_PATHvariable, but that is a build-time setting.In Git for Windows' context, that is not good enough: we want to use the very same Git artifacts both in the regular MinGit flavor as well as in the BusyBox one.
So let's introduce support for the config setting
core.shell, which is interpreted as the absolute path of the POSIX-compliant shell to use to execute hooks, scripted Git commands, complex aliases, etc.We also set the environment variable
SHELLifcore.shellwas configured. This helps the scenario where OpenSSH is called in a BusyBox variant of MinGit (which comes without any MSYS2 shell): OpenSSH looks at that variable to run commands such as ones specified via theProxyCommandsetting in the SSH config.Note: in the BusyBox variant of MinGit, we will want to set this in the system config, to a path relative to the runtime prefix. For that reason, we will need to address gitgitgadget#66 rather sooner than later, before going through with this here PR.