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

21

4

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.

Screen grab of environment variables

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.

mawcsco

Posted 2013-05-10T14:44:58.667

Reputation: 633

2I think you need to reboot after making the changes for them to take effect. – Enigma – 2013-05-10T15:02:18.790

@Enigma Why? I didn't need to reboot in Windows 7, Vista, XP, 2000... – mawcsco – 2013-05-10T15:08:42.467

@mawcsco You did in 7 at least. Opening command prompts from the start menu launches with the environment from the Explorer shell, which was loaded when you logged in. You need to either kill/restart explorer, log out or back in, or restart the system. – Darth Android – 2013-05-10T15:17:21.740

@mawcsco - I needed to reboot in 7 for PATH changes to take effect. Have you tried a reboot yet? – Enigma – 2013-05-10T15:38:06.693

1

@Enigma A reboot should not be necessary. http://serverfault.com/questions/8855/how-do-you-add-a-windows-environment-variable-without-rebooting

– mawcsco – 2013-05-10T15:41:49.487

@mawcsco - So then whatever is the issue here may be an issue for me as well. "Any programs spawned via Explorer after this should get the updated environment, although already-running programs will not, unless they handle the setting change message." – Enigma – 2013-05-10T17:22:43.977

1I've just checked this on both Windows 7 and Windows 8: in either case the new environment variable was visible in cmd when a new instance was launched. Of course the already running cmd didn't get the updated environment. – Alexey Ivanov – 2013-05-10T17:39:38.420

@AlexeyIvanov I've just created a video with the problem on my Windows 8 Machine. When YouTube is done "processing" I will post the link. – mawcsco – 2013-05-10T21:15:16.213

@Enigma I think it's reasonable to conclude that there is an issue and that it may have existed in Windows 7, thus you've experienced a similar issue in Windows 7. Alexey Ivanov indicates that he does not experience this issue and we tried to reproduce it on my neighbor's Surface Pro with no luck. – mawcsco – 2013-05-10T21:17:06.623

Try changing something in the system path instead of the user path. – jdigital – 2014-03-08T00:53:44.210

Answers

7

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.

Darth Android

Posted 2013-05-10T14:44:58.667

Reputation: 35 133

1@mawcsco It worked for me, I'm using Windows 7. – laike9m – 2015-09-12T03:09:41.493

Maybe the behavior was changed in an update to Windows 7? – binki – 2016-01-28T22:41:11.183

1This is Feb 2016 and I'm using Windows 10. But this answer from 2013 saved me from much confusion and frustration. I use Authotkey to launch Powershell so that if an Explorer window is active, Powershell opens in that folder. After reading this answer, I launched Powershell from Start Menu and voilà, the path is up-to-date and everything works fine. Then again launched Powershell with Autohotkey — back to un-updated path. I'm leaving this comment here for other fellow confused souls. – ba_ul – 2017-02-18T01:19:15.910

2Absolutely false for Windows 7. See the video I linked in my post above. – mawcsco – 2013-05-10T15:34:51.793

1Huh. You're definitely correct there, though I've definitely had my changes not apply immediately to new console windows on Win 7 before. I can't remember what my exact workflow was, though. I'll play around with my Win 8 system when I get home if nobody has an answer for you by then. – Darth Android – 2013-05-10T15:49:02.290

5If you changed environment variables using System properties dialog, the changes are applied immediately to the currently running Explorer instance, and all processes started afterwards get the new environment. Already running processes do not automatically update their environment variables unless they handle WM_SETTINGCHANGE message. – Alexey Ivanov – 2013-05-10T17:44:56.520

1Dude, this helped me understand the problem I was having anyway. I use AutoHotkey to launch a command prompt, and it wasn't working until I restarted autohotkey! – Moss – 2014-03-14T22:01:15.797

3

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.

Enigma

Posted 2013-05-10T14:44:58.667

Reputation: 3 181

It wouldn't surprise me that this is an implementation detail and that Microsoft had no intentions of supporting this behavior in Windows 8 or above. – surfasb – 2016-01-26T18:59:50.347

2Windows Explorer in Windows 7 handles this message, and it's enough to restart Command Prompt from Taskbar or Start menu. – Alexey Ivanov – 2013-05-10T17:31:52.590

"Changes to environment variables should take effect immediately, if you make the change via the main Properties dialog for the computer in question (go to My Computer | Properties | Advanced | Environment Variables). After the changes are saved, Explorer broadcasts a WM_SETTINGCHANGE message to all windows to inform them of the change." http://serverfault.com/questions/8855/how-do-you-add-a-windows-environment-variable-without-rebooting

– mawcsco – 2013-05-10T17:39:06.157

2"System Tip This article applies to a different version of Windows than the one you are using. Content in this article may not be relevant to you. Visit the Windows 8 Solution Center" – mawcsco – 2013-05-10T17:41:04.867

1

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.

Vu Gia Truong

Posted 2013-05-10T14:44:58.667

Reputation: 121

I think you might have missed the detail in my screenshots and video that shows the dialog with "User variables for mwillia3". That's my username. I know for certain that I was editing the correct environment variables. The C# app fires the event, with the old value, not the updated value. I gave up. I'm fairly certain this is a Win 8 bug and I no longer have access to Windows 8 to test this. – mawcsco – 2014-10-01T14:48:32.453

Some people don't always read the details. I see this on some systems and not on others, I've even seen it on Windows 7/2008. There is no rhyme or reason for when it happens that I've found. – ferventcoder – 2015-06-18T22:47:43.233

Same problem with Windows Server 2012 r2 even after propagating WM_SETTINGSCHANGED. I believe it's a windows bug. – vezenkov – 2016-03-28T13:47:44.867

0

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

elder elder

Posted 2013-05-10T14:44:58.667

Reputation: 306

0

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

kct

Posted 2013-05-10T14:44:58.667

Reputation: 1

1Can you explain why SETX rather than SET works. – ChrisF – 2014-05-10T13:51:21.257

First, I wasn't using the command line, I was using the system dialog. Second, my pattern of behavior works fine in Windows 7, but sometimes not in Windows 8. Can you point to documentation that shows how SET and SETX changed between Windows 7 and Windows 8? – mawcsco – 2014-05-12T13:43:25.503

0

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.

viktorkh

Posted 2013-05-10T14:44:58.667

Reputation: 1

-1

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...

user348438

Posted 2013-05-10T14:44:58.667

Reputation: 1

Even in Windows 8 the Start Screen UI seems to all be part of explorer.exe because it disappears when explorer.exe is killed. – binki – 2016-01-28T22:43:46.307