Normally, if I define one User Windows 10 environment variable (var 1) in terms of another (var 2), var 2 should precede var 1 in alphabetical order for it to work.
This is identified here, e.g.
For instance, in the window
this
APYTHONDIR -> C:\Users\user1\myprogs
PATH -> %APYTHONDIR%
works, but this
PYTHONDIR -> C:\Users\user1\myprogs
PATH -> %PYTHONDIR%
does not.
Is there any way of avoiding it?
Working around it?
I mean to get a solution that functionally works the same as if the variables were defined via registry (or Control Panel).
I can always use naming to ensure "nested" definitions follow alphabetical order.
This is not what I want.
I thought about setting them in the desired order in a startup batch file (autoexec.nt
, or whatever is current).
I am not sure if this would work for any application requiring the environment variables.
E.g., octave symbolic integration needing to find python
somewhere in the PATH
, with the directory in the PATH
being added in this way.
EDIT As per the answers by harrymc and myself, and following discussion, this is what I tried:
-
Creating a file
set_env_vars.bat
in an arbitrary directory, and set a shortcut to it in%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
. -
Adding a line
set /P PTEST=Enter value for PTEST
inset_env_vars.bat
to make sure the file is being read during logon. -
Logging off and on. I verified that
set_env_vars.bat
is read.
Then, I added lines
set ZTEST_DIR=C:\ztest
set YTEST_DIR=%ZTEST_DIR%;C:\ytest
to set_env_vars.bat
.
Plus log off / log on.
This didn't give me vars ZTEST_DIR
and YTEST_DIR
in my environment.
Then, I replaced those with lines
setx ZTEST_DIR C:\ztest
set /P WAITING_DUMMY=Enter value for WAITING_DUMMY
setx YTEST_DIR %ZTEST_DIR%;C:\ytest
in set_env_vars.bat
.
(The second line to try giving time to the system to set the first var).
Plus log off / log on.
This gave me vars
YTEST_DIR=;C:\ytest
ZTEST_DIR=C:\ztest
in my environment.
Best Answer
If you do
set "a=x%b%y"
, thena
is defined exactly like that, and%b%
will only be expanded when required. This is why alphabetical order has no importance. Variables are substituted when their value is required, andPATH
is an example of a value that is immediately required.To automate setting environment variables, put the SET commands in a batch file (
.bat
) and copy the file to the Startup folder.Your personal startup folder should be
C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
, while the All Users startup folder should beC:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
.Question: What am I doing below that is different than what you do? You could show us a similar screenshot if you are getting different results.
As regarding the example you have posted, the results are as expected. You have used the
setx
command, which sets environment variables for the user in the registry, but not in the local environment. You would need to start a new Command Prompt from the desktop to benefit from that variable.The important point here is that
setx
works on the registry, but that does not cause the local environment to be re-evaluated. The environment is built only once, when a process is launched, then stays the same all through execution (unless modified locally by the process itself). Any child started by a parent process will inherit its parent's environment, so no reference is made in that case to the registry.The demo below demonstrates the problem: The variable is set in the above Command Prompt, but doesn't have a local value. The lower Command Prompt is then started from the desktop, and it does have that value.