I have a theory about how and why __CD__ behaves in a different way than any other environment variable.
I wrote a simple ENV.JS script to test the process environment.
var env=WScript.CreateObject("WScript.Shell").Environment("Process"); WScript.echo(env(WScript.Arguments.Item(0)));
ENV.JS expects the name of the environment variable as a single argument and simply prints the value of the variable. I tested on a computer with Windows 7. The script can be launched from the CMD.EXE console, or it can be launched directly using the shortcut that defines the argument.
I will classify various dynamic variables, showing contrasting behavior, as well as a theory regarding the mechanism by which they work.
There are a number of dynamic variables that can be divided into three classes:
1) Normal "variables" without prefix or suffix
CD current directory DATE current date TIME current time ERRORLEVEL current errorlevel RANDOM random integer between 0 and 32767 CMDEXTVERSION current extension level (only available if extensions are enabled) CMDCMDLINE the command line that invoked the current CMD.EXE level
Dynamic values are available only through the extension in CMD.EXE and only when command extensions are enabled. They are not available through SET, or ENV.JS. Dynamic values can be overridden by explicitly defining a static value using SET. Override values are available through SET and ENV.JS.
C:\test>echo %cmdcmdline% "C:\Windows\system32\cmd.exe" C:\test>set cmdcmdline Environment variable cmdcmdline not defined C:\test>cscript //nologo env.js cmdcmdline cmdcmdline= C:\test>set cmdcmdline=override C:\test>echo %cmdcmdline% override C:\test>set cmdcmdline cmdcmdline=override C:\test>cscript //nologo env.js cmdcmdline cmdcmdline=override C:\test>cmd /e:off Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\test>echo %cmdcmdline% %cmdcmdline%
Dynamic values are not environment variables at all, so they are not available for SET or ENV.JS. The code of the extension variable in CMD.EXE first checks the process environment variables for the variable, and only if it is not found, it compares this name with a list of special dynamic names. For each dynamic "variable", a special CMD.EXE code must exist to obtain a value from the corresponding source.
The behavior of this class of dynamic variables is described by Microsoft Raymond Chen on his blog - The Old New Thing
2) Dynamic variables with a prefix =
=ExitCode =ExitCodeAscii =C: =D: ... =Z:
Each of these dynamic values is undefined until any command that defines it is executed. For example, a new CMD.EXE console session starts with = ExitCode undefined. It becomes detectable after executing an external command that sets the return code.
There is one exception, because the variable ={driveLetter}: corresponding to the current directory will always be determined even when CMD.EXE is launched first.
You cannot use SET to define any of these variables, because SET does not allow = in the variable name. But the main variable space of the process environment allows = in variable names. This needs to be done only outside the context of CMD.EXE.
I wrote an additional TEST.JS to check these variables:
var shell=WScript.CreateObject("WScript.Shell"); var env=shell.Environment("Process"); WScript.echo('Within JScript: ExitCode='+env("=ExitCode")); env("=ExitCode") = "override"; WScript.echo('Within JScript after override: ExitCode='+env("=ExitCode")); WScript.echo('Within JScript test.bat return code = '+shell.run("cmd /c test.bat",10,1)); WScript.echo('Within JScript after test.bat: ExitCode='+env("=ExitCode"));
In turn, TEST.JS calls TEST.BAT:
@echo off echo Within test.bat: ExitCode=%=ExitCode% cmd /c exit 10 echo =Within test.bat: ExitCode=%=ExitCode% pause exit %errorlevel%
Below are some test results using =ExitCode , starting with a new CMD.EXE session:
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\test>echo %=ExitCode% %=ExitCode% C:\test>set "=ExitCode=override" The syntax of the command is incorrect. C:\test>cscript //nologo env.js =ExitCode =ExitCode= C:\test>REM cscript is an external command that set the value! C:\test>echo %=ExitCode% 00000000 C:\test>set = The syntax of the command is incorrect. C:\test>set ""|findstr /b =ExitCode =ExitCode=00000000 C:\test>cscript //nologo env.js =ExitCode =ExitCode=00000000 C:\test>cscript //nologo test.js Within JScript: ExitCode=00000000 Within JScript after override: ExitCode=override Within JScript test.bat return code = 10 Within JScript after test.bat: ExitCode=override C:\test>
Here are the results of TEST.BAT that TEST.JS launched in a new window:
Within test.bat: ExitCode=override Within test.bat: ExitCode=0000000A Press any key to continue . . .
I believe that these dynamic variables are true environment variables, so both SET and JScript can access them. (SET can only access a value using the special SET "" syntax.) Variables are dynamically determined (or updated) by CMD.EXE each time the relavent command is executed. ENV.JS and TEST.JS can see the value set by the calling CMD.EXE session. In the TEST.BAT cmd session, you could see the inherited override value set by TEST.JS. But JScript continued to get the override value after the TEST.BAT exit because CMD.EXE was not there to update the value with the return code.
This class of dynamic variables is available whether command extensions are enabled or disabled. Dynamic values are retained even if extensions are disabled, as shown below:
C:\test>cmd /e:off Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\test>echo %=c:% C:\test C:\test>cd test C:\test\test>echo %=c:% C:\test\test
3) __CD__ - A special case for everyone!
EDIT - In fact, __APPDIR__ works the same way.
This dynamic variable is always available for both CMD.EXE and JScript. An override value can be specified, but neither CMD.EXE nor JScript can see the override value, except that the SET command can display an override value. (Also not shown, but jeb discovered that SET / A can read an override value if it is numeric).
I wrote another TEST2.JS to test this variable.
var shell=WScript.CreateObject("WScript.Shell"); var env=shell.Environment("Process"); WScript.echo('Within JScript: __CD__='+env("__CD__")); env("__CD__") = "JS override"; WScript.echo('Within JScript after override: __CD__='+env("__CD__")); shell.run('cmd /c "set __CD__&pause",1,0');
The following are some test results:
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\test>echo %__CD__% C:\test\ C:\test>set __CD__ Environment variable __CD__ not defined C:\test>set "__CD__=Batch override" C:\test>echo %__CD__% C:\test\ C:\test>set __CD__ __CD__=Batch override C:\test>cscript //nologo test2.js Within JScript: __CD__=C:\test\ Within JScript after override: __CD__=C:\test\ C:\test>
Here is the result of the CMD.EXE window opened by TEST2.JS:
__CD__=JS override Press any key to continue . . .
If I define a shortcut for ENV.JS as follows:
Target: C:\test\env.js __CD__ Start in: C:\test\xyz
Then, when I click on it, I get a warning window:
__CD__=C:\test\xyz\
I find these results fascinating. Dynamic value should not be a true environment variable. Presumably, there is a low-level OS environment access routine that automatically returns the current directory of the process whenever it is prompted to return the __CD__ value. It does this even if a true static environment variable named __CD__ .
The CMD.EXE SET command must access an environment variable that is different from most other contexts. I assume that the C program can be written to get a pointer to the memory of the process environment and __CD__ any true user-specified __CD__ value, as well as the SET command.
Given that this is a low operating system that provides this value, it is not surprising that %__CD__% is available even when command extensions are disabled.
C:\test>cmd /e:off Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\test>echo %__cd__% C:\test\ C:\test>cd test C:\test\test>echo %__cd__% C:\test\test\
I assume that the concept of the current directory is critical for each process from an OS perspective, and MS decided to give the process access to the value using a dynamic virtual environment variable. XP OS allows you to extend any overridden __CD__ value. Perhaps this caused problems for some applications, and MS decided to change the environment access procedures (starting from Vista, maybe?), To always return the real current directory, regardless of any custom __CD__ variable.
So, based on the theory that this is a low-level procedure that returns the current directory, now I believe that it is impossible to use your own command commands to reliably get any custom value for __CD__ .