Why won't my Windows 8 Command line update its path

Question

I needed to add a new entry to my PATH variable. This is a common activity for me in my job, but I've recently started using Windows 8. I assumed the process would be similar to Windows 7, Vista, XP...

Here's my sequence of events:

1. Open System properties (Start-> [type "Control Panel"] -> Control Panel\System and Security\System -> Advanced system settings -> Environment Variables)
2. Add the new path to beginning of my USER PATH variable (C:\dev\Java\apache-ant-1.8.4\bin;)
3. Opened a command prompt (Start -> [type "command prompt" enter] -> [type "path" enter]

My new path entry is not available (see attached image and vide). I Duplicated the exact same process on a Windows 7 machine and it worked.

EDIT

Windows 8 Environment Variables and Command Prompt video

EDIT

This is definitely not the behavior of Windows 7. Watch this video to see the behavior I expect working in Windows 7. http://youtu.be/95JXY5X0fII

EDIT 5/31/2013

So, after much frustration, I wrote a small C# app to test the WM_SETTINGCHANGE event. This code receives the event in both Windows 7 and Windows 8. However, in Windows 8 on my system, I do not get the correct path; but, I do in Windows 7. This could not be reproduced in other Windows 8 systems.

Here is the C# code.

using System;
using Microsoft.Win32;

public sealed class App
{
    static void Main()
    {
        SystemEvents.UserPreferenceChanging += new UserPreferenceChangingEventHandler(OnUserPreferenceChanging);

        Console.WriteLine("Waiting for system events.");
        Console.WriteLine("Press <Enter> to exit.");
        Console.ReadLine();
    }

    static void OnUserPreferenceChanging(object sender, UserPreferenceChangingEventArgs e)
    {
        Console.WriteLine("The user preference is changing. Category={0}", e.Category);
        Console.WriteLine("path={0}", System.Environment.GetEnvironmentVariable("PATH"));
    }
}

OnUserPreferenceChanging is equivalent to WM_SETTINGCHANGE

C# program running in Windows 7 (you can see the event come through and it picks up the correct path).

C# program running in Windows 8 (you can see the event come through, but the wrong path).

There is something about my environment that is precipitating this problem. However, is this a Windows 8 bug?

EDIT 2014-04-28

Due to this and several other issues, we no longer use Windows 8 on the desktop. We do not have an environment to continue testing and experimenting with this problem. There is still no answer or resolution to this problem for us. The answers below did not resolve our problem.

Answer 1

If you are launching the Command Prompt from the start menu or a shortcut on your task bar, you must either:

• Restart explorer. Kill it and relaunch it.
• Log out and back in (which effectively relaunches explorer).
• Restart the system (which also effectively relaunches explorer).

The environment doesn't update immediately because environments are inherited from their parent process, with the exception of explorer, which is started by the system upon login. This is how it behaves on my Windows 7 system.

So changing the Environment Variables updates the registry keys, but these keys are not re-read until the system has to build a new login environment for some process being launched. Most of the time, this isn't happening because processes are children of a process which already has an environment, so the environment is inherited.

Answer 2

From: http://support.microsoft.com/kb/104011 via https://serverfault.com/q/8855/158027

...

However, note that modifications to the environment variables do not result in immediate change. For example, if you start another Command Prompt after making the changes, the environment variables will reflect the previous (not the current) values. The changes do not take effect until you log off and then log back on.

To effect these changes without having to log off, broadcast a WM_SETTINGCHANGE message to all windows in the system, so that any interested applications (such as Windows Explorer, Program Manager, Task Manager, Control Panel, and so forth) can perform an update. MORE INFORMATION

---

For example, on Windows NT-based systems, the following code fragment should propagate the changes to the environment variables used in the Command Prompt:

SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,
    (LPARAM) "Environment", SMTO_ABORTIFHUNG,
    5000, &dwReturnValue);

None of the applications that ship with Windows 95 and Windows 98, including Windows Explorer and Program Manager, respond to this message. Thus, while this article can technically be implemented on Windows 95 and Windows 98, there is no effect except to notify third-party applications. The only method of changing global environment variables on Windows 95 is to modify the autoexec.bat file and reboot.

Answer 3

The problem is with your user setting. In Window 8, each user has it own environment variables.

Open System properties (Start-> [type "Control Panel"] -> Control Panel\System and Security\System -> Advanced system settings -> Environment Variables)

Above approach will edit environment variables for the root user, maybe not your current user.

You should go to user-account -> select your current account -> change environment variables

After changing, restart power shell. Then

echo $env:JAVA_HOME

or

Get-ChildItem env

Hope this will help you.

Answer 4

Try SETX instead SET. E.g SETX PATH "%PATH%;MyPath"

Answer 5

If you are using Windows 8.1, open the command prompt as Administrator, then call the PATH command and you should see it appear there. When you go back to normal cmd, it will also show up. And as matter of fact, you should be able to start the added application from command prompt.

Answer 6

Late to his. However. You may be a victim of this issue: User variables are not resolved correctly in Windows.

Answer 7

Does it work if you use Win+R from the Desktop to start cmd.exe? My guess is that starting it from the Start Screen causes the started cmd.exe's parent to be different from explorer.exe (WSAHost.exe, IIRC or whatever it's named), and that parent process doesn't update it's environment during WM_SETTINGCHANGE messages. I don't have a Windows 8 machine on hand to test...