11

So, is there a limit to how deeply environment variables can be nested in Windows? I do a lot of development work and I'm trying to set up my development environment vars, and a lot of them nest off each other, ie.


GLEW=%THIRD_PARTY_ROOT%\GLEW
GLEW_1_5_5=%GLEW%\glew-1.5.5
GLEW_BIN_PATH=%GLEW_ROOT%\bin
GLEW_INCLUDE_PATH=%GLEW_ROOT%\include
GLEW_LIB_PATH=%GLEW_ROOT%\lib
GLEW_ROOT=%GLEW_1_5_5%

OSG=%THIRD_PARTY_ROOT%\OpenSceneGraph
OSG_2_8_3=%OSG%\OpenSceneGraph-2.8.3
OSG_BIN_PATH=%OSG_ROOT%\bin
OSG_INCLUDE_PATH=%OSG_ROOT%\include
OSG_LIB_PATH=%OSG_ROOT%\lib
OSG_ROOT=%OSG_2_8_3%

THIRD_PARTY_ROOT=C:\dev\third-party

But I was having a heck of a time getting them to actually expand properly. For a while when I looked at the output of set, I was just getting what looked like they were being expanded in order and so any ones that depended on foo_ROOT weren't being expanded properly. I tried enabling delayed expansion and that didn't help, but restarting seemed to... so maybe delayed expansion required a restart..

Either way, I have GLEW_BIN_PATH and OSG_BIN_PATH in my PATH variable and they refuse to expand. This is really frustrating because the dll's are residing there and of course I can get evvvverything else to expand... any thoughts?

Edit: I have them in the PATH variable as:

[everything else....];%GLEW_BIN_PATH%;%OSG_BIN_PATH%

So I'm not seeing an obvious cause to keep them from expanding out..

trycatch
  • 111
  • 1
  • 3

5 Answers5

14

It looks like there is a lexicographic dependency on the variables definition.

Windows expands and populates the Enviroment Variables on lexicographic order (:-O)

You can only use on your variable, variables that are "lexicographically" lower than your variable.

Example: Following Definition:

VAR_01=1
VAR_02=%VAR_01%-2
VAR_03=%VAR_02%-3

Produces

VAR_01 is 1
VAR_02 is 1-2
VAR_03 is 1-2-3

But

VAR_01=1
VAR_02=%VAR_03%-2
VAR_03=%VAR_01%-3

Produces

VAR_01 is 1
VAR_02 is -2
VAR_03 is 1-3

Due VAR_03 is not defined when VAR_02 is expanded.

Domin
  • 463
  • 3
  • 10
  • Great answer. But what about *special* variables? Why %USERPROFILE% in %TEMP% works while %USERNAME% doesn't? (It's shown correctly in sysdm.cpl but is ignored (and replaced with system value) in real apps) – Basil Peace Aug 16 '21 at 16:23
  • 1
    This answer is not always correct. For Microsoft Terminal, current order of resolution is described [here](https://github.com/microsoft/terminal/issues/9741#issuecomment-815420501): "registry key enumeration order is arbitrary". Also from that discussion follows the conclusion that there is no consistent way used by all Windows apps to set environment block. Each application can use its own algorithm and so could have different problems – Basil Peace Aug 16 '21 at 17:03
  • And regarding USERPROFILE and TEMP, if order used by explorer is the same as Microsoft Terminal then it answers my question. USERPROFILE is resolved before registry values, but USERNAME after. And I was wrong on using system TEMP variable, looks like before resolution USERNAME is set to SYSTEM – Basil Peace Aug 16 '21 at 17:03
  • To be honesto, I have the feeling that env variables handling is one of the less consistente implementation in Windows and I dont asume anything about expanding them and try to avoid its use. Any case considera that the handling of vars by apps is or it could be different, they could be expande by the app code itself – Domin Aug 18 '21 at 05:54
1

Yeah, this is driving me crazy. Full repro by:

System Properties, Environment Varialbles, set up like so:

one = c:
two = %ONE%\two
three = %TWO%\three

Then click OK, and run cmd. Here's what I see:

C:\>set one
one=C:

C:\>set two
two=C:\two

C:\>set three
three=%TWO%\three

This link explains for Vista, but does not mention that it happens on Win7. http://support.microsoft.com/kb/911089

...Jonas

Jonas
  • 11
  • 1
1

I've had success with escaping the percent sign:

GLEW=%%THIRD_PARTY_ROOT%%\GLEW

THIRD_PARTY_ROOT=C:\dev\third-party

C:\>set GLEW
GLEW=C:\dev\third-party\GLEW

When viewing the variable from the Windows Environment Variable window, it will display as

GLEW | %THIRD_PARTY_ROOT%\GLEW

Note: The double percent signs will only work inside a script. If using on the command line, use the caret escape character (e.g. GLEW=^%THIRD_PARTY_ROOT^%\GLEW).

justDev7a3
  • 171
  • 1
  • 9
0

Have you saved all of the needed variables in the System Variables as well? Because in order to expand the values, the system will have to have a "permanent" memory of all the needed variables.

If you do all these together in a row on the command line, just saying X=something and Y=%X%;else, then when you set the path to PATH=%PATH%;%Y%, the shell expands the values of all the variables before it saves the new value of PATH; but as soon as you close the Command Prompt window, the system has forgotten %X% and %Y% entirely.

However, if you use the System Properties Control Panel to set the PATH to include the unexpanded variables, than all those variables are going to have to exist as system variables when you reboot, or they'll fail to expand.

To ensure that you are saving all the variables in the system so that they are still there after the reboot, either use the System Properties Control Panel or the SETX.EXE command. If you are going to use them in the system PATH (not just your user account's path), then you'll want to use SETX /M X=blah or the bottom part of the System Properties | Environment Variables tab, labeled "System variables".

ewall
  • 27,179
  • 15
  • 70
  • 84
0

I have been experiencing this in Windows 10, build 1903.

For me, the solution was to remove the PATH variable from 'user' (the upper half of the system properties dialog) and keep only the path in 'system'. Restart the cmd.exe shell or use refreshenv to reload the properties, and expansion should work again.

This looks like a bug in Windows for how it resolves user vs system properties, or possibly the processing order. For me it was not replacing values in the user PATH with values from the 'system' set of env vars. It might work better if all the variables are in user, but I've not tested this hypothesis.

antonyh
  • 2,131
  • 2
  • 21
  • 42