Sam Heywood wrote:
>D:\TEST>dr
>Command or filename not recognized
>
>D:\TEST>DIRMAGIC (C) Copr. 1988 ZD Co
>Command or filename not recognized
>
>D:\TEST>Michael J. Mefford
>Command or filename not recognized
>D:\TEST>
>
>- ------------------------------------
>
>It appears that command.com tried three times to execute
>the program. Each time an error message was returned by
>command.com. The first two lines of DR.BAT were output to
>the screen, not just the first line. So, it appears to me
>that some parts of the program actually ran. They did run,
>although with some problems and difficulty.
- --
Wrong!
Your command interpreter tried to interpret what was offered to it in the
input file. The approach for interpreting an input file is to strip the
whitespaces and some control sequences right to the essential text and to
try to get something usable out of it. Like a coincidence, the first tens
of bytes in your dr.com file are text strings, and, pretty important, they
contain CR\LF's, so, from the command.com's parser point of view, *they
are lines of text*, so they can be interpreted.
The behaviour of the command interpreter is to extract every line of text
from a .bat file and to * echo * it to the screen at the cursor position
like it was typed from the keyboard. The CR/LF sequence (end of line) acts
like pressing the ENTER key, so it instructs the parser to get to work on
it. The parser will do its job and, in case of a unintelligible
combination of characters, will issue the error message
"Command or filename not recognized". Then, the command prompt will again
appear on the screen, and the cycle will resume. We observe that the
process of executing a batch file, only involves rerouting the standard
input (normally the keyboard) to that file.
A "@" sign at the beginning of a line means that particular line should
not be echoed to the screen before interpreting it
The "@echo off" line supresses all the echoing of the input to the screen.
I am not sure, but I believe that lines longer that 128 chars won't be
interpreted and would cause the command interpreter to stop and exit.
Cristian Burneci
Bucharest, Romania
