Certain DOS Commands under XP = Bad command

March 24, 2011 at 11:53:00
Specs: Windows XP
Given: Large group of mixed XP Pro/XP Home (all SP3) systems running a FoxPro 2.6 application that calls a DOS batch file

Issue: Running the simple batch file gives "Bad command.." or "Out of environment space" on 50% of the machines, but the other 50% run it just fine.

Question: Why don't some of the machines recognize basic DOS commands?

Running the batch file manually from a command prompt (cmd.exe) works great on all of the machines. But calling for the execution of the same batch file from FoxPro results in the errors on that 50%.

Here's a sample batch file script, similar to the one used here:

@echo off
h:
CD h:\dir\program
:WAITLOOP
IF NOT EXIST "%2" (
MOVE %1 %2
START /MIN /WAIT program
) ELSE (
GOTO WAITLOOP
)
...continues...

When the script reaches the 5th line, I get the "Bad command..." error over and over again until I kill the process, as it reiterates WAITLOOP. By including the PAUSE command after each command, I see that it is the IF command that generates the error.

However it really doesn't matter ... whether it is IF or MOVE or START at that line, it generates "Bad command ..."

Interestingly, COPY, DEL and other similarly ancient commands do NOT generate the error, so I have rewritten the script to use only 1st-generation DOS. Unfortunately, this means I cannot use loops to test for file existence, etc., so my current script has no error checking and, since I cannot use the START command to force a WAIT until the process finishes, that makes me very nervous.

Additionally, when I attempt to capture the %ERRORLEVEL% with each command, used like I did with the troubleshooting PAUSE commands, I not only get "Bad command..." errors, but I ALSO get "Out of environment space" errors.

I have tried adding "/e:200000" (using obscenely high numbers) to the execution string that fires the batch file from FoxPro, and a couple of other similar things, including increasing the memory available to the environment in XP, without any effect. I've been going back and forth trying different execution strings, but nothing has made any difference, in a good way.

I do note a possible clue on the bad machines; when I launch the batch file with:

cmd.exe /k batchfile.bat

FoxPro blows right by it without an error and without executing the batch file.

Using:

c:\windows\system32\cmd.exe /k batchfile.bat

Errors with "The system cannot find the path specified". It's weird.

So, I'm calling "batchfile.bat" directly without invoking cmd.exe, first, which executes the batch file, but then I get the error(s) noted above.

COMSPEC is set to cmd.exe, and these are all fully patched systems. We really can't see any significant differences between the configuration of those machines that can handle the script and those that can't.

Any thoughts on how I can use commands like IF, MOVE and START on ALL Windows XP workstations?
Where should I look for more troubleshooting actions I can take?
Do you think the "environment space" errors have something to do with this?

Thanks for any help, at all. Seriously. Anything.
I've been banging my head against this for a week!


See More: Certain DOS Commands under XP = Bad command

Report •

#1
March 24, 2011 at 14:21:13
XP is NT kernel based so there is no DOS under it; however XP offers two command interpreters, the native cmd.exe compatible with legacy DOS and command.com strictly bound to old DOS commands.

If your batch is activated from a legacy application as FoxPro the command.com is called by default causing yor troubles. So you need to launch cmd.exe (how I don't know).

Inside FoxPro try cmd.exe /C your batch or launch FoxPro by a shortcut coding explicitly cmd.exe. Why 50% machines are fine and the others no is a mistery, but this not the focal point.


Report •

#2
March 24, 2011 at 16:53:09
Thank you for your reply.

Yes, NT-based systems emulate DOS by using their NTVDM (NT DOS Virtual Machine). My guess as to what was happening (old interpreter didn't 'get' newer commands) is the same as yours.

Unfortunately, forcing the use of cmd.exe via FoxPro in any number of ways did not do the trick. I described a couple of them, above. FoxPro forums have not been helpful, but perhaps I need to persist in them.

I am also very curious about the "environment space" errors when attempting to grab the %ERRORLEVEL%. Why would an XP installation have issues with the memory available to the environment specs? Even running FoxPro 2.6 it seems odd that NTVDM's memory management would not take care of that.

Thanks, again.


Report •
Related Solutions


Ask Question