How do 'Adjusting your PATH environment' options work within the bash.exe?

[Okeanos]

I want to better understand how the settings for 'Adjusting your PATH environment' work within the confines of the bash.exe, i.e. what happens after installation when GP_Cmd or GP_CMdTools is picked and how do they manipulate the PATH.

In git-for-windows/build-extra/installer/install.iss I can see what happens during installation (lines 3220-3248) or removal (lines 3775-3792). This results in Git (and optionally subcomponents such as OpenSSH) to be added to Windows' PATH.

Now, the end result in the Windows Environment Settings for the System PATH will look something like this for GP_Cmd:

…
%SystemRoot%\system32
%SystemRoot%
…
%SystemRoot%\System32\OpenSSH
…
C:\Program Files\Git\cmd
…

Based on that at least within non-bash programs the path behaves exactly as expected in that order.

Within the bash.exe, however, invoking env will print something like this (ellipses corresponding to the same holes as above):

PATH=/c/Users/win10vm/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/win10vm/bin:/c/Windows/system32:…:/c/Windows/System32/OpenSSH:…:/usr/bin/vendor_perl:/usr/bin/core_perl
ORIGINAL_PATH=/mingw64/bin:/usr/bin:/c/Users/win10vm/bin:/c/Windows/system32:…:/c/Windows/System32/OpenSSH:…

When an export PATH="/some/prefix:$PATH" exists e.g. in .bashrc or .bash_profile for example this will be prefixed for bash.exe, however, obviously not for $PATH as defined in the Windows Environment Settings. Likewise, adding either User or System $PATH variables via the Windows Environment Settings will not actually put them at the front of the final bash.exe $PATH - even though they'll appear 'correctly' in the $ORIGINAL_PATH.

So, I understand that the PATH options for the installer only only affect the Windows side of things – say Powershell or what have you.

Now, I am wondering where the business logic for prefixing the values such as /c/Users/win10vm/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin happens because I am interested in being able to only manage in what order executables are found in a single place, namely the Windows Environment Settings, regardless of whether it's in the bash.exe or not. Is that even feasible?

[rimrul]

That happens in git-wrapper.c, look for my_path_append.

Remember that it's there so all the unix-ish programs get found before the windows programs of the same name.

I'd expect many things to break (some in potentially subtle ways) if you remove this.

[Okeanos]

I would assume that instead of simply prefixing or suffixing the path doing an infix solution isn't easily possible, i.e. $USER_PATH:$GIT_PATH:$SYSTEM_PATH instead of the current $GIT_PATH:$USER_PATH:$SYSTEM_PATH?

[rimrul]

Not easily. No. As far as environment variables are concerned there is no split into $USER_PATH and $SYSTEM_PATH. That means, we'd have to produce this from the registry or guess where to insert the infix. And even with that infix solution, there are plenty of things that could lurk in the user part of $PATH that would break Git.

[Okeanos]

True enough – but it would be the user's fault and user fixable ;-). Thanks for your insights, very helpful.