System versus user PATH environmental variable...winmerge works only if I add the path to the user PATH

Question

If I add C:\Program Files (x86)\WinMerge to the User PATH variable(by right click on computer -> advanced system settings -> environmental variables), once I open a new cmd shell WinmergeU.exe is not recognized. If I add that path to the System PATH variable, WinmergeU.exe is correctly recognized instead. I though there was no difference between User and System, beside the fact that if I set it on System all the users will see it, while the User PATH is local. Am I doing something wrong?

EDIT 1:

In the follow you can see first the case in which C:\Program Files (x86)\WinMerge is added to the System PATH variable (but not to the User), then when it is added to the User PATH variable (but not to the System). In the first case Winmerge window launch correctly (not shown) and as you can see the path is shown by the echo %PATH% command. In the second case it does not launch and the path it is not shown by echo %PATH%. (note that I clearly confirmed with OK and closed the environmental variable windows before taking these screenshots, and I opened a new cmd right after changing PATH and pressing ok). This issue might be related to my question here (Does echo %PATH% expand to only the system or also the user variables?) but since it might not be I posted two different question.

Intermix

Answer 1

You must be getting something wrong, or have environmental problems with your machine. Adding a user PATH environment variable does result in it being merged into the environment of a new process.

Update: Perhaps this comment from the MSDN topic on environment variables might be pertinent:

Found out that on Windows Server 2003, once the system PATH passes 1920 characters, the user PATH environment variable is no longer merged with it to set the process PATH environment variable, even though the full system PATH (even if larger) will be included in the process PATH variable.

Discrepancy

I posted the screenshots. It makes a difference in my computer. – Intermix

Then you are doing it wrong, or your OS is broken. Works fine here and on every other machine I've ever used. Perhaps it doesn't help that your path is so long. But I don't expect that's really the problem. – Discrepancy

I am not doing wrong... I did it three times...I confirmed with OK and closed the environmental variable windows before taking the screenshots, and I opened a new cmd right after changing PATH and pressing ok, and I reopened the environmental variable window only for taking the screenshot. I dont see what I can do wrong. Echo %PATH% only displays System PATH. – Intermix

Bingo! Yes I just found it out myself after you pointed out that the path was too long. Getting rid of some entry solves the problem. So annoying. Thanks – Intermix

I encountered exactly the same issue and resolved it by pruning path entries which were in the system and user portions of the path. – Subchaser

Thanks for finding this. I just ran into it as well. Indeed, very annoying. – Lemures

I just had another issue with user PATH and system PATH...#29891614 I witnessed something I cannot explain. Appreciate if you can drop by. – Hooper

I have solved my issue. It's DLL collision during path resolution. – Hooper

This solved git/grunt not being found in the path while building in Visual Studio 2015 – Olaolaf

Answer 2

On Windows 7, also make sure that the system path does not end with a backslash. If it does, the USER PATH is appended to the system path as per usual, but after a line break, which breaks things. In the latter case, the simple command "path" and "echo %PATH% " will print 2 different outputs.

Pule

Answer 3

For 16.6, I've confirmed this issue to be a path length issue as well. At a cmd prompt, typing 'set', you can see all of the env. variables. The user path cadence variables and others weren't included. I saved the original complete path text, then I went through and trimmed specific (system) path elements that were deemed unnecessary. after this, in a new cmd session, typing 'set' now shows the user path elements tacked on to the end of the system path elements, because they now fit.

Levelheaded