UPDATE NO.2 - Now to the actual question: Why do nested, user-created variables fail to expand?
There's some general problems concerning variable expansion in Windows. I've already run into the same problem and found no clear, reproducible circumstances - the recursion level at which expansion fails is not consistent, special characters don't seem to play a role, etc.
The only viable workaround I found is adding variables recursion level by recursion level. That means: Try deleting all variables you want to nest into each other (including calls from PATH to your user-defined variables), and then start up from scratch. Define your basic variables (etc. ANT-HOME), commit, check if it's expanded, if it is, go on with the next level commit, check... you get the idea.
UPDATED ANSWER - Defining permanent environment variables using the CLI and GUI - Scroll down for the original answer
GUI method:
On Windows 7, just type "system" in the META-Prompt and you'll see an entry "Edit the System Environment Variables". From there, click "Environment variables". There, you can either edit the system variable PATH (bottom list) or add/edit a new PATH variable to the user environment variables.
Command line method:
To change environment variables permanently, you have to use the SETX command in the Windows command line. Unlike in other versions of Windows, it comes built-in with Windows 7. Its syntax differs a lot from SET, but it's also powerful. You'll have to be a bit careful though, it's easy to make a mess of your variables with SETX.
By default, you change user variables. You can have a PATH user environment variable that happily coexists with the system PATH variable. If you don't have it defined yet, do so by typing: SETX PATH yourpath
You can also add a value to the system variable PATH. To do this, you first need to bring up a command line with admin privileges. To do this, hit the Meta(Windows) key, type cmd
and hit CTRL
+ SHIFT
+ENTER
and confirm the UAC dialog.
To add new values to path, you can now enter
setx path "%path%;yournewpath" /m
It's important to follow that syntax! If you don't include %path% first, all existing values of path will be lost and replaced with only you new path.
The /m switch at the end sets the variable in the system environment.
Please note that you'll have to bring up a new command line to make use of your new variable.
There's also a full reference for SETX at TechNet.
OLD ANSWER
The command SET updates the variables only for the duration of the current command line session.
The correct syntax for adding a value to a variable is 'set [variable]=%[variable]%;[new value]`
Note that left of the equal sign, you have to omit the percent signs!
Source: TechNet Command-line reference for Windows Server
According to the MSKB article Environment variables in Windows NT:
User environment variables....take precedence over system environment variables.
One notable exception is the PATH
variable which is a combined result of the system and user variables:
The Path is constructed from the system path, which can be viewed in the System Environment Variables field in the System dialog box. The User path is appended to the system path.
The article also discusses identical exceptions for the expansion of the LibPath
and Os2LibPath
variables as well as how those specified in autoexec.bat
are handled. These points are likely to find little relevance in today's typical environments.
Credit to this SO answer
Best Answer
Your conclusions aren't quite right, at least according to my testing.
User variables can reference system (global) ones.
System variables cannot reference user variables.
User variables will override system (global) ones.
Just in the default set,
TEMP
(andTMP
) are defined as the user variable as%USERPROFILE%\AppData\Local\Temp
and at the same time as the system variable asC:\Windows\TEMP
.PATH
appears to be a special case, where the user variablePATH
(if defined) is always appended to the system variable rather than overriding it.