I have a DOS build script which works on one Windows Server 2008 R2 but not another. To see the symptoms on the broken machine entering either of the following at the command li
Check the COMSPEC
environment variable in on the machine where it doesn't work, i.e. do echo %COMSPEC%
and see what it contains (it should be %windir%\system32\cmd.exe
or comparable).
Long Story:
You're detailed question ruled out all other potential possibilities (like the need to use %%X
instead of %X
inside batch files, as compared to the command line), like fiddling with setlocal enableextensions
(or comparable switches, registry entries, etc.). And by the way, the error message would not fit.
If you get the error message "...is not recognised as an internal or external command" it is, that CMD.EXE cannot find the command you're trying to execute. Since "dir" is an internal command "this should never happen", of course.
I was able to reproduce your error doing the following:
CMD.EXE
SET ComSpec=DoesNotExist
CMD.EXE
, i.e. start another, nested, CMD.EXE
session. This step is required, in a running CMD.EXE
session, the change to ComSpec
seems to go unnoticed.CMD.EXE
session enter your command (e.g. for /F %x in ('dir /b') do @echo%x
), you should get the error you see. Note if you just enter dir
it will still work, so you have to have that "indirect" execution via, e.g., a for
loop. Funny.Note that this was all done to reproduce what you are seeing, the reasons exact environmental or setup conditions that lead to this behavior on your system might be different, however the fact that the ComSpec
environment variable refers to something other than CMD.EXE
should be the same.
In a batch file you have to use double-percents i.e. %%X. At the command line single percents are fine.
As to why it works on one machine, not sure, perhaps its somehow being run via 16 bit DOS on the machine which works? Or it was a different test that appears to work without the variable substituion working.