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.EXESET ComSpec=DoesNotExistCMD.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.