I am using the following to create and edit environment variables for Windows 7.

Control Panel\All Control Panel Items\System -> Advanced system settings -> Environment Variables

Under System variables I have the following pertinant variables:

PROG32=C:\Program Files (x86)
REALDWG_SDK_DIR=%PROG32%\Autodesk\RealDWG 2011

However, the following happens:

C:\>echo %PROG32%
C:\Program Files (x86)

C:\>echo %Path%
%REALDWG_SDK_DIR%;C:\Program Files (x86)\Haskell\bin

Is it possible to have a chain of variables expand?

If I rename Path to something else, I sometimes get the problem, and sometimes I don't.

  • Why don't you use setx to set the variables instead? That way they will be expanded before entering the registry. – paradroid Jan 14 '11 at 9:11

Edit: After experimenting with this a bit more, the actual problem appears to be related to the variable name(s) -- perhaps some kind of bug in the parser that expands nested variables. It appears that the nested variable that you are adding needs to come before the top level variable if they were sorted alphabetically.

As an example, changing REALDWG_SDK_DIR to OEALDWG_SDK_DIR will work, as will BEALDWG_SDK_DIR, but PEALDWG_SDK_DIR will not, nor will ZEALDWG_SDK_DIR. Alternatively, renaming PATH to SATH will work, but RATH will not.

Thus, the solution to your problem is to use something that starts with a letter before P, or else manually type out the first part of the path.

Initial (incorrect) answer:

What you're doing should be working. Check to make sure you don't have a typo in one of the variable names somewhere along the way -- that's the only reason I can think of that would cause it to just print the name without expanding. Also, you will need to open a new command prompt after applying the changes.

  • I second the typo theory. – user3463 Jan 14 '11 at 2:40
  • It's not a typo, and I am opening new prompts ever time I change the variables. If I take the PROG32 variable out of REALDWG_SDK_DIR, PATH expands fine. Also, if I rename PATH to something else, it sometimes works fine and sometimes doesn't. – Thomas Eding Jan 14 '11 at 3:10
  • Interesting... I see what you mean now; I get the same results when using the values you have listed there... aaand, I think I just found the problem -- I'll edit my answer. – Herohtar Jan 14 '11 at 8:35
  • Thanks. I would accept, but for some reason, I don't own the question. Probably because it was a migrated question and I later made this account here. – Thomas Eding Jan 14 '11 at 16:49
  • Also note that if you add the variables using the setx-command, the new variables will come last in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment). But if you open the 'Environment Variables' dialog and click OK this will sort the registry entries and this may change the result of the variable expansion! – Nils Lande Sep 24 '18 at 14:33

I wonder if this may related to this defect on Microsoft's Knowledge Base:


I've encountered the same problem with environment variables on some XP systems (not only %APPDATA%, like the KB article is about). Using various methods to set the environment variables, including both ones mentioned in the KB article, were of no help... neither was setx (Windows Resource Kit tool).

However, the exact same methods worked on other systems. It is very frustrating - the only solution I've found seems to be using explicit paths rather than environment variable references (which sucks, but works).



rather than:


EDIT: For the past while, I have just been using mklink (http://technet.microsoft.com/en-us/library/cc753194.aspx) to create Junctions (basically symbolic links) rather than mussing around with environment variables and their buggieness. For example, rather than MYVAR as an env var, I just create c:\myvar - it can point to E:\some\really\long\and\hard\to\remember\let\alone\type\path or whatever you wish. mklink is consistent, can be created via the command line, and they persist between reboots. Eg:

mklink /j c:\myvar c:\something
mklink /j c:\myvar E:\some\really\long\and\hard\to\remember\let\alone\type\path

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.