Question

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 line:

for /f %X in ('dir /b *.txt') do @echo %X
for /f "usebackq" %X in (`dir /b *.txt`) do @echo %X

gives: “‘dir /b *.txt’ is not recognised as an internal or external command.” while e.g.

for %X in (*.txt) do @echo %X

works fine, so the /f is not being obeyed properly. I don’t believe this is the Command Extensions themselves (starting cmd /x shows the same behaviour; running them inside cmd /y on the problem server gives the normal “/f was unexpected at this time”). I have also checked the command extensions registry keys and tried “setlocal enableextensions” in the batch files.

I don’t think it’s relevant but differences between the servers are that the failing one is physical; its CPU doesn’t have VT extensions; does have McAfee installed. As far as I know they were installed the same way though at different times.

Does anyone have any suggestions? I am stuck!

Answer 1

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:

1. Start CMD.EXE
2. Enter the following SET ComSpec=DoesNotExist
3. Enter the following 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.
4. In the new 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.