RFC: /o:PathOption=CmdToolsMinimal

[delan]

note: this patch is obviously incomplete, but it’s a request for feedback containing the core idea only.

the installer currently has three options for what to add to PATH:

• Use Git from Git Bash only (/o:PathOption=Bash) does not add anything
• Git from the command line and also from 3rd-party software (/o:PathOption=Cmd) adds [INSTALLFOLDER]cmd only, allowing git and friends to be run from anywhere
• Use Git and optional Unix tools from the Command Prompt (/o:PathOption=CmdTools) also adds [MingwFolder]bin and [INSTALLFOLDER]usr\bin, allowing the full suite of unix tools to be run from anywhere

/o:PathOption=CmdTools is useful because it puts bash on PATH, and many “composite actions” (CI subroutines) on GitHub Actions expect to be able to run bash scripts on all platforms (servo/ci-runners#53). GitHub’s first-party CI images use that option, but it clearly has potentially unwanted side effects like overriding find and sort, so we’re reluctant to use it in our own CI images.

but we noticed there’s an [INSTALLFOLDER]bin directory with just bash + git + sh, and adding that to PATH allows bash to be run from anywhere without any side effects. even better, when you’re inside that bash, PATH has access to all of the unix tools anyway (it starts with /mingw64/bin:/usr/bin:).

would the option below be compelling to provide in the installer? are there any problems it might cause?

• Use Git and bash from the Command Prompt (/o:PathOption=CmdToolsMinimal) adds [INSTALLFOLDER]cmd and [INSTALLFOLDER]bin only, allowing git and friends, sh, and bash to be run from anywhere

[delan]

update: while writing the issue, i noticed that /o:PathOption:CmdTools doesn’t actually seem to override find and sort (notice the windows find and unix grep), so maybe the installer text needs an update?

[dscho]

/o:PathOption=CmdTools is useful because it puts bash on PATH, and many “composite actions” (CI subroutines) on GitHub Actions expect to be able to run bash scripts on all platforms (servo/ci-runners#53). GitHub’s first-party CI images use that option, but it clearly has potentially unwanted side effects like overriding find and sort, so we’re reluctant to use it in our own CI images.

update: while writing the issue, i noticed that /o:PathOption:CmdTools doesn’t actually seem to override find and sort (notice the windows find and unix grep), so maybe the installer text needs an update?

CmdTools does override find/sort: It either shadows C:\Windows\system32's versions with the MSYS2 versions, or vice versa, depending on the order in which the respective folders appear in PATH. No matter what you do, you either break Unix shell scripts expecting GNU find, or you break CMD scripts expecting the Windows find.

but we noticed there’s an [INSTALLFOLDER]bin directory with just bash + git + sh, and adding that to PATH allows bash to be run from anywhere without any side effects. even better, when you’re inside that bash, PATH has access to all of the unix tools anyway (it starts with /mingw64/bin:/usr/bin:).

would the option below be compelling to provide in the installer? are there any problems it might cause?

• Use Git and bash from the Command Prompt (/o:PathOption=CmdToolsMinimal) adds [INSTALLFOLDER]cmd and [INSTALLFOLDER]bin only, allowing git and friends, sh, and bash to be run from anywhere

I am very hesitant about that:

• Since Windows also has a bash.exe (which runs WSL, and predates wsl.exe AFAICT), we'd face the exact same shadowing problems as for find and sort.
• That bin folder is not advertised much because I merely introduced it as a backwards-compatibility thing for software predating Git for Windows v2.* that assumes that there is a bash and git in C:\Program Files\Git\bin. It's not something I wanted to support, originally, and I did not exactly want to start advertising it now...

In any case, CmdToolsMinimal strikes me as a name that wants to be improved. It would probably need to be something like CmdAndBash, but again, I am reluctant to advertise this as an option. Too many people rely on Bash being distributed with Git for Windows already, limiting our ability to switch to a more performant Unix shell (in case one comes around, maybe this one).

[delan]

CmdTools does override find/sort: It either shadows C:\Windows\system32's versions with the MSYS2 versions, or vice versa, depending on the order in which the respective folders appear in PATH. No matter what you do, you either break Unix shell scripts expecting GNU find, or you break CMD scripts expecting the Windows find.

i’m not sure this is entirely true; when testing that setting on our end (see screenshot above), [INSTALLFOLDER]usr\bin always gets appended to the end of PATH, after %SystemRoot%\system32, so CMD scripts will continue to use the Windows find and sort. but inside Git Bash, /mingw64/bin:/usr/bin: always gets prepended to the start of that PATH, so Unix shell scripts should use the MSYS2 find and sort.

that said, the rest of your comment kinda makes that moot.

I am very hesitant about that:

• Since Windows also has a bash.exe (which runs WSL, and predates wsl.exe AFAICT), we'd face the exact same shadowing problems as for find and sort.

oh, i didn’t know about that, good point!

• That bin folder is not advertised much because I merely introduced it as a backwards-compatibility thing for software predating Git for Windows v2.* that assumes that there is a bash and git in C:\Program Files\Git\bin. It's not something I wanted to support, originally, and I did not exactly want to start advertising it now...

yep that’s fair, i suspected it might be something sketchy like that :)

In any case, CmdToolsMinimal strikes me as a name that wants to be improved. It would probably need to be something like CmdAndBash, but again, I am reluctant to advertise this as an option. Too many people rely on Bash being distributed with Git for Windows already, limiting our ability to switch to a more performant Unix shell (in case one comes around, maybe this one).

also fair enough. would it be reasonable for a dependent project like ours to avoid relying on Bash in Git for Windows by using /o:PathOption=Cmd and installing our own MSYS2?

[dscho]

would it be reasonable for a dependent project like ours to avoid relying on Bash in Git for Windows by using /o:PathOption=Cmd and installing our own MSYS2?

That should work. I do hope that we'll get to a point where MSYS2 distributes a mingw-w64-git that is virtually identical to Git for Windows' (and maintained by the latter project), in which case you could totally stay within the MSYS2 ecosystem and still benefit from Git for Windows.

[delan]

thanks! i’ll give that a shot :)