Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just installed gvim on my Windows system (it's on C:\gvim, anyway). Then I add C:\gvim\vim73\ on the user PATH, not the system PATH. After that, I tried to invoke vim from the command prompt. Nope, it didn't work. So I removed gvim directory from the user PATH to system PATH. It did work.

I'm still curious, so I do a "echo %PATH%", and the result is everything from the system PATH.

My understanding is the system PATH has a higher priority than user, so Windows first will try to search the system PATH, and after that the users'. So it should have worked, but it didn't.

share|improve this question
Did you log the user out and back in after making the original change? It won’t take until the user profile is reloaded. – Synetech Oct 27 '11 at 18:47
User environment variables always override system ones. But %PATH% is an exception - Windows will merge system and user values, in that order. So you're right about its priority. – grawity Oct 27 '11 at 20:54

You're not actually setting any environment variables of any form when you modify the registry.

Environment variables are not kept in the registry. What is kept in the registry is a template, from which programs like Windows Explorer (re-)construct their environment variables when notified to do so. Actual environment variables are per-process and are stored in each process' own address space, initially inherited from its parent process and modifiable thereafter at the process' whim. The programs like Windows Explorer participate in a voluntary protocol, whereby they will re-read the template, and update their own per-process environment whenever a Windows message is broadcast to all (top-level) windows on a desktop.

Many Win32 programs do not participate in this voluntary protocol. Microsoft's command interpreter is one such program. To modify an environment variable within a running Microsoft command interpreter process, one uses the ordinary command interpreter commands for modifying environment variables, such as SET, DPATH, and PATH. The modified environment will be inherited by every process that the command interpreter spawns.

Similarly, the modified environment in a Windows Explorer process is only inherited by processes that are spawned by Windows Explorer after it has received the message and re-read the template. The environment variables of an already running process are not affected by modifications made by other processes to their own environment variables. An already running Microsoft command interpreter won't magically gain a changed environment from the Windows Explorer process that spawned it before the change.

Other command interpreters differ. JP Software's TCC, for example, itself participates in the voluntary protocol. It will recognize the Windows message, and update its own per-process environment from the template in the registry, when its "Update Environment on System Change" setting is enabled.

share|improve this answer
+1 Appropriate information for this topic. – Daniel Beck Oct 27 '11 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .