Windows git bash - child processes see system PATH environment variable instead of user...

This happens on my Windows 7 Home Premium x64 SP1 Desktop, but not on my Windows 10 Pro x64 laptop.

Everything used to work fine until I updated my Desktop to the latest version of Git (the laptop has the same version but was a totally clean install as it is a new laptop)

Edward@Edward-PC MINGW64 /f/Work $ echo $PATH ...(USER PATH)...

Edward@Edward-PC MINGW64 /f/Work $ cmd Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.

F:\Work>echo %PATH% echo %PATH% ...(SYSTEM PATH)...

The same is true of any child process (e.g. node.js) - they all see SYSTEM PATH now instead of USER PATH. I have tried clean reinstalling git. I have tried both the 64-bit and 32-bit versions of git.

Used Process Explorer to investigate the environment of the processes on the 2 machines. The only significant difference I can see is the PATH variable in cmd.exe.

If I double-click bash.exe (instead of the shortcut to git-bash.exe) then the user PATH is seen by child processes. Double clicking git-bash.exe, still has the problem. Running bash -l from a cmd window, has the problem.

Run bash.exe, then sh echo $PATH // Shows user path cmd echo %PATH% // Now shows system path So bash saw user path, sh saw user path but then cmd was passed the system path?!

Run bash.exe followed by cmd, cmd, cmd, etc - cmd always sees user path. So bash -l and sh both see user path but then only forward system path to child processes...

sh definitely used to work as well as the git bash shortcut (I know because I run git bash > grunt > sh and that now sees the wrong/incomplete path when before it was working fine)

I have spent most of this frustrating day trying to figure out what is going wrong but do not have a clue.

I have no .bashrc or .bash_profile files on either system (no idea what these are for but a colleague was trying to help diagnose the problem - they ultimately came up empty). As far as I can tell the 2 systems are set up exactly the same (apart from the different Windows versions of course). Path length is not an issue as the (working) laptop has a huge path whereas the (not working) desktop has less than 500 characters.

Unfortunately I don't know what version of git I had before, and older versions aren't offered for download so I can't trial and error. Really wishing I hadn't upgraded!

Any assistance would be much appreciated as I am totally pulling my hair out now.

Many thanks and kind regards,

Edward Marshall

Hi Edward,

On Wed, 17 Feb 2016, Edward Marshall wrote:

I presume this is Git for Windows 2.7.1(2), installed via the default installer?

And I also assume that you run this in Git Bash?

Can you test whether this also happens in the PortableGit from https://github.com/git-for-windows/git/releases/latest? (These are self-extracting .7z archives, just install them somewhere else than your current installation, it won't touch your Start Menu or desktop icons.)

The Git Bash is available in the portable installation as git-bash.exe in the top-leve directory.

Are you sure that it is "instead of"? AFAICT both Git CMD and Git Bash should have the full PATH, i.e. both system and user PATH concatenated.

Now, this is interesting. Maybe something funky does happen in some strange place in the Bash profile.

If you can reproduce this with the portable Git, it would be good to insert the line "set -x" at the top of %PORTABLEGIT%\etc\profile (that is the correct file name IIRC, it could also be bash.bash_profile, but I think the latter is included by the former). Then start bash -l again, and see whether you can find the place where it sets the PATH.

To be certain, I would also recommend outputting the PATH with which Bash starts, either by inserting a line "echo $PATH" at the top of the profile file, or by starting bash without -l option.

Could be a .profile, too, maybe.

Older versions are still available (we did not remove any) from https://github.com/git-for-windows/git/releases (and if you look for the 1.x series that was using a completely different Bash/MSYS: https://github.com/msysgit/msysgit/releases).

Ciao, Johannes

Hey, thanks for getting back to me. I subseuqently found the git-for-windows issues tracker on github so have posted an updated version of this there - not sure where is the best place for issues.

I have also found that the cause was having %VPROJECT%..\bin inside my user PATH but no VPROJECT environment variable. Removing the path or adding the missing env var fixes the problem. This suggests that something is failing to concatenate user PATH to system PATH when it can't expand the non-existent environment variable.

fwiw, I don't have a .profile file either.

Hopefully you can replicate the problem with the above info, but please let me know if you still want me to run anything or if there is anything else I can do to help.

Kind regards,

Edward Marshall

On 19 February 2016 at 11:08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Hi Edward,

On Fri, 19 Feb 2016, Edward Marshall wrote:

It is the best place for Windows-specific issues. Thanks for following up!

Ciao, Johannes