home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-387-Vol-3of3.iso
/
r
/
rcx10.zip
/
BAT2EXEC.BUG
next >
Wrap
Text File
|
1993-01-29
|
7KB
|
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 | GROENEVELD@CMI.TNO.NL | \_/ | | |
( CMI-TNO ) | Y. Groeneveld | GROENEVELD@CMIHP1.UUCP | Jim Groeneveld
P.O.Box 124 | Wassenaarseweg 56 | GROENEVELD@TNO.NL | 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