Tools en Utilities/CDASS_5.ISO/shell/comp/rcx10.arj/BAT2EXEC.BUG

Text File | 1993-01-29 | 6.8 KB | 99 lines

BAT2EXEC.BUG - Bugs (and other pecularities) in BATch file compiler:
    BAT2EXEC 1.5 (c) 1990, 1991 Ziff Communications Co.
    PC Magazine ~ Douglas Boling.
Of the three BAT compilers I have this is the most compatible one.

More or less severe bugs.
1. If ECHO statements write more than 14 lines to a diskfile (via redirection)
   then subsequent ECHO lines without redirection want to write to the PRN
   device instead of to the CONsole. This may be "corrected" by redirecting
   subsequent ECHO's, as well as some other internal commands, such as PAUSE,
   that write to standard output, explicitely to CON. This "correction" does
   not work for many other internal and external DOS commands, external
   programs and within external batch files: these even DO NOT RUN if
   redirected to ANYTHING (e.g. CD, COPY, DIR and TYPE), while they print on
   PRN if not redirected at all! Is seems that something in memory gets
   confused, which can not be corrected. ECHO (and PAUSE) can be corrected
   because they are handled by the compiler itself (within the compiled file),
   while (all) other commands are executed by shelling out to (a confused) DOS.
   This is a rather severe bug! (This also applies to prefixing ECHO with CALL.)
2. ECHO lines that begin with the characters "on" or "off" whether followed by
   any other text or not are always interpreted as their equivalent batch
   commands (in contrast to DOS: if "on" or "off" is followed by more text then
   the whole line is text and "on" of "off" are not interpreted). Commands
   never are echoed from the compiler, so such lines will not be displayed.
3. While redirecting standard output (to a file, e.g. via ECHO) extra spaces
   corresponding to the redirection part on the original line are written to
   the output file. (This isn't necessaryly an important bug.)
4. Constructs like 'FOR %%A IN (%1 %2 %3 %4 %5 %6 %7 %8 %9) DO.....etc.',
   that involve wildcards (* and ?'s) in one or more replaceable parameters are
   processed buggy by BAT2EXEC. How buggy is unpredictable, but it is
   certainly erroneous. Such constructs should be changed (split mostly)
   into a number of separate lines such as 'FOR %%A IN (%1) DO.....etc.',
   'FOR %%A IN (%2) DO.....etc.', etc. or otherwise as one likes.
   Besides, simple forms, such as 'FOR %%A IN (%3) DO ECHO %%A' (or instead of
   ECHO any other command INVOLVING %%A, the replaceable parameter), where %3
   is any wildcard, do not execute correctly at all: the test on the existence
   of a wildcard seems correct, but the substitution of the parameter %%A in
   the part after the DO is incorrect for the first (or only) file name
   corresponding to the wildcard! This makes such forms completely useless.
   The SOLUTION for these problems is to add the DOS command CALL just before
   the FOR command. This causes the FOR command not to be processed by the
   buggy compiled program, but from the DOS command processor. A slight
   disadvantage is that the evaluated command gets displayed visibly on the
   screen and that it is somewhat slower, because a copy of COMMAND.COM has to
   be loaded.
5. The DOS internal CTTY command does not seem to be effective because it is
   executed from a temporary DOS shell (not from within the program, cf. SET).

Other differences with DOS BATch language:
1. %0 in a batch file only returns the literal call to the file;
   %0 in a compiled program returns the full drive:\path\filename.ext of the
   called program (ext=COM/EXE), independent of how it was called (to start).
   This may be an undesired 'feature', in any case %0 is much longer.
2. DOS allows for special treatment of a slash within a 'for' list (see file
   UNDOCU'D.DOS). The compiler doesn't regard the slash special, so slashes
   within a 'for' list are treated as all other characters. This should not
   be a problem, because it was not documented and thus in DOS goes differently
   than expected, if compiled it works as expected. If one would want to use
   this feature from a compiled batch file though, one may prefix the FOR with
   the CALL command, causing the FOR to be executed by DOS. However, a 'GOTO
   label' after the DO (and eventual IF) does not work from a 'CALL FOR' line!
   Only commands that echo something (eventually redirected) or start another
   program work, but references to labels in the current program don't.
3. A file to redirect to should initially be created with a single > character.
   A double >> does not implicitely create it as in DOS; in such a case the
   redirection is ignored and output goes to standard output (which may have
   changed from CON to PRN by another bug). Bug or feature?
4. The command line 'echo 7' in which '7' is actually the ascii value 7,
   causing a beep and a CRLF on the output device, is suppressed completely
   by the resulting compiled program. In order to get it function one should
   include at least some printable character (not equal to a space), for
   instance the ascii character 255, that prints as a space. Thus: 'echo #7',
   in which '7' is ascii character 7 and '#' is character 255, works!
5. Redirecting or piping a normal BATch file at call time makes no sense: it is
   not effective. Redirecting (or piping) the input for or output from a
   compiled batch script at call time (at least with BAT2EXEC), however, is
   effective!  Redirected input does not occur in (compiled) batch files,
   except for some special internal DOS commands (such as DATE, TIME and
   DEL *.*). Output to redirect, that normally goes to the screen (CON),
   concerns all output not explicitely redirected within the compiled script,
   so all messages from internal DOS commands (as long as not written to the
   standard error device), such as from COPY, DIR and ECHO. This redirection of
   _ALL_ standard (input and) output remains in effect as long as the called
   compiled script is running, also if it calls real BATch files (!) and other
   compiled batch scripts and in fact any external program for which no other
   (explicit) redirection of standard output has been specified.
   Redirection of standard (input and) output of compiled batch scripts
   generally is not intented and applied, but in specific cases there may be a
   useful application for it.
6. The main environment can not be changed using SET commands; these are only
   effective in the temporary DOS shell created and lost immediately.

Centrum voor Medische Informatica TNO       <Email>              |  |  |\/|
TNO Center for Medical Informatics | [e-mail]  |  \_/  |  |  |
( CMI-TNO )    | Y. Groeneveld     | [e-mail] | Jim Groeneveld
P.O.Box 124    | Wassenaarseweg 56 | [e-mail]      | Schoolweg 14
2300 AC Leiden | 2333 AL Leiden    | (28 January 1993)      | 8071 BC Nunspeet
Nederland.     | (+31|0)71-181810  | Fax (+31|0)71-176382   | 03412-60413