On my Pc, running Windows XP 5.1.2600, following
"My Computer" > "Properties" > "Advanced" > "Environment Variables" > "Path"
I get a string, but in a batch file, or directly typing from prompt, by means of
echo %path%
I get a different one.
Can someone, please, explain what makes them differ and how to fix the issue, setting the "DOS-path" to the same value of "Windows-PATH" ?
Two things:
As others have mentioned, the full value of PATH is the combination of the user's PATH variable and the system's PATH variable.
If you change environment variables (including PATH), any processes already running (including the Command Prompt) will continue using the old environment variable values. You will need to restart those processes to pick up any changes that you've made.
The value of the PATH environment variable you see on the command line (which has nothing to do with "DOS" btw) is the sum of the system wide PATH variable and the user specific PATH variable.
If you open the dialog with the system variables from within the control panel, the upper part contains the user specific environment variables. The lower part contains the system variables.
If you set a PATH variable for your user to e.g. c:\foo, and the system path is be c:\Windows\System32 then you'd see c:\Windows\System32;c:\foo when you do an ECHO %PATH% on the commandline.
Probably the difference you are seeing is that when a new process is made, its default environment contains a PATH variable that is made by merging the system variable with the user variable.
As for how to "fix the issue", there is nothing to fix. The system behaves as designed.
I was getting the same issue where the System Variable that I get through the
"My Computer" > "Properties" > "Advanced" > "Environment Variables" >
"Path"
was different that the one being displayed through the command line interface via
ECHO %PATH%
The fix for this is basically to wait for the change to take place and this can be made faster by restarting the cmd and explorer. To do that you can simply end task for Explorer and CMD and then start a new task or restart it directly.
The same shall be done for the CMD as well.
The Windows registry can hold path entries that do not show up in the Environment Variables version of PATH you see via the control panel. (Why, I do not know).
The difference means that something (likely an install script) made changes to the registry.
To view or change the local user's path variable, look in the HKEY_CURRENT_USER\Environment key.
To view the system path, look in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
Related
I have an external computer with an IP address like 100.12.5.7 and I would like to set a path to the environment variable like so:
setx MEDIA \\\100.12.5.7\d\media\
When I tried the above command, cmd prompt me that the variable is set successfully but when I do an echo %MEDIA%, it only shows me %MEDIA% instead of the full path. Any idea how I could fix this?
Setx doesn't affect the current console. Use Set and Setx together. Set, unlike Setx, requires an equal sign.
The reason setx can't affect the current console is that a copy of the starting program's environment is passed to programs it starts (usually Explorer's environment either direct or indirect via CMD). So all changes are local to that program. Setx sets registry keys, so only new programs can read them, and that really mean CMD.exe, as that rereads the registry keys.
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.
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.
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.
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.
I found a way to change the default home directory of a user but I am having trouble with it.
Doing this will change the home drive to C:
But then when I check the environment variable:
It is still H:, with a system restart the Enviroment variables in windows settings will also return to H:/
I have also tried changing it like this:
Which appears to work but if i open a new cmd it will have reverted back to H:/
Now I am trying to do this so that OpenSSH will recognise C as my home directory instead of H: which is a network drive, forcing OpenSSH not to work unless I cam connected to my university network via VPN.
What can I do to set this permanently and in the eyes of OpenSSH?
Nowhere does it mention a dependency between the HOMEDRIVE value and the HOMEDIRECTORY value, what was happening (I think) is that it was failing to map the home directory to the HOMEDRIVE and therefore defaulting back to a safe value (C:)
I wrote a script to update the local AD, replace the values in [] with your values. Copy and paste into a .vbs file and double click on it to run it.
Set objUser = GetObject("WinNT://[COMPUTERNAME]/[USERNAME],user")
objUser.homeDirDrive = "H:"
objUser.HomeDirectory = "[URNPATH]"
objUser.SetInfo
e.g.
Set objUser = GetObject("WinNT://UQBDART-2328/BEN,user")
objUser.homeDirDrive = "H:"
objUser.HomeDirectory = "\\SERVER\SHARE"
objUser.SetInfo
run this, reboot and test. It worked for me.
Sounds like the AD profile on the domain is overwriting the user defined variables. I see your screenshot says you are connected to the eait.org.edu.au domain. That will be the root of your issue. Just to include some details here that I spotted elsewhere, that may be of help to you:
HOMEDRIVE, HOMEPATH & HOMESHARE are set and updated via Active Directory. HOMEDRIVE & HOMEPATH are set even without a home drive set on the account; however they will be overridden by any user account properties set in AD.
Also see these KB articles:
http://support.microsoft.com/kb/841343
http://support.microsoft.com/kb/237566
http://support.microsoft.com/kb/101507
On a side-note for another way around the issue:
-I have in the past created a new instance of the windows command-line shell executable that automatically runs a custom script, so everytime you launch the shell, the environment variable could be overriden.
-To do that you could just put the code you posted to change the environment variable into a batch script, stored wherever you like, then edit the shortcut(s) used to launch the shell by going to properties > then alter the Target box: %SystemRoot%\system32\cmd.exe /K "C:\Documents and Settings\Administrator\My Documents\customshellscript.cmd" (Obviously the part of the path after /K is the location of your custom script)
This way, if you are using openSSH over the console anyway, it will always have the homedrive set correctly.
Changing those environment variable's values is not "supported", at least it will not work as you expect because Windows changes them back.
According to this Microsoft knowledge base article (KB841343), you should use policies, if you need to change these settings. The article also contains links for how to do that (but personally, I never tried). Note that the article was originally written for Windows 2000, but I would strongly suspect, that it is still valid for current Windows versions.
Back in the days of DOS the environment variables were part of the Program Segement which meant that you basically got a local snapshop of the variables limited to the scope of that program.
I'm guessing Windows hasn't changed this and the environment variables available to the CMD window only have the scope of that window and any further windows it spawns. This is supported by this little experiment:
in a CMD window type
set homedrive=h:\
and then test it's updated by typing
set h
from this same window type
start cmd
and in this new window type
set h
when I've done this I get HOMEDRIVE=H:\
if I then just open a new CMD window from the start menu and do the same SET H I get HOMEDRIVE=C:\
I don't know anything about OpenSSH but I suspect like the START CMD got the updated HOMEDRIVE environment variable, if you write a batch to update the environment variable and then execute OpenSSH that'll work.
I had a similar issue, the HOMEDRIVE variable was set to U: which was a drive we no longer used. This was just for one particular user. I went to that user's profile in AD and clicked the Attribute Editor tab. There was an attribute for HOMEDRIVE which I changed from U: to C: - when the user logged in again, it was set correctly. I also updated the HomeDirectory attribute here.
This issue had been really frustrating me trying to find a solution, but I have found what I think is the definitive answer and posted it at:
https://stackoverflow.com/a/60235759/12903197
You need to run 'net user USERNAME /homedir:PATH' where USERNAME is the name of the user you are trying to change and PATH is the drive letter and full path to the desired home folder, which must already exist.
On windows 8:
Hit "windows key".
type "system environment variables".
Allow "Advance system settings" to make changes.
Select "Advance" tab.
Click on "Enviroment Variables...".
Double click on "Path" from "User variable for XXXXXXXX"
Add at the end the variable the new path that you want separated by semicolon.
e.g. C:\Program Files\;C:\Python27\
shareeditdelete (1)flag
I'm writing a dos-batch in which I need to change the PATH.
I'm using the SET command.
The batch is run from the command line (cmd.exe).
The problem : the changes are only available for the cmd window, and I soon as this window is closed, the changes are dismissed.
How can I change the PATH from a batch and make sure the change will affect the whole system ?
There is a tool setx.exe provided in the Windows XP Service Pack 2 Support Tools that can be used to permanently change an environment variable from the command line:
setx path "%PATH%;C:\New Folder"
Source: http://vlaurie.com/computers2/Articles/environment.htm
The above link also gives the location of the registry keys that store the system / user environment variables - if you are feeling adventurous you could also try setting those.
User environment variables:
HKEY_CURRENT_USER\Environment
System environment variables:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
I am using a machine where I do not have administrator privileges and I need to set the e.g. JAVA_HOME each time I boot.
Thus, I'd like to write a script that sets the desired classpath automatically.
How do I do this?
You surely can set the environment variables with a batch file each time you need them, but bear in mind that this will only work for the current process (i. e. the cmd instance you're invoking the batch from) and processes spawned from there. I think you'd rather want persistent environment variables.
Now, in the UNIX world you'd just put them into your shell startup script. In Windows ... not exactly that way.
Right click on "My Computer", select "Properties".
There, go to the "Advanced" tab
Click the button labeled "Environment variables"
You can set JAVA_HOME and GRAILS_HOME under "User variables" there.
You would only need administrator access for changing the system environment variables.
You would want a file with .bat extension for Windows.
SET JAVA_HOME=path
SET GRAILS_HOME=path
On Windows, you could write a .BAT file (BATch), and then simply double-click it each time you log in. a .BAT file is simply a plain text file filled with any commands you would normally issue at the command prompt, e.g.:
cd c:\Temp
c:
set PATH=%PATH%;c:\Program Files\Some Directory\Some Subdirectory
You can optionally precede each line with the # symbol to stop it being echoed to the command window when it executes.
Try calling the following :
SETX JAVA_HOME path
SETX GRAILS_HOME path
If you're allowed they will be set in your profile and you won't need to run them again hopefully. Other wise you'll need to follow #Android's answer