On Thu, 6 Jul 2006 16:14:14 +1000, "Pegasus \(MVP\)"
I assume your questions are all answered, you are now aware
of the inbuilt label ":eof"
I'm wondering if there's a mis-understanding here.
Ye olde DOS batch files were in "ASCIIZ", i.e. an 8-bit ASCII
character set ("low" half ASCII, "high" half the IBM OEM character set
ASCII extension) plus Ctl+Z as the "end of file" marker. As in...
Copy Con: SomeName.bat
(type type type type)
(type type type type)
(type type type type)
^Z
The ^Z (Ctl+Z) closes the file, and writes the character as the
end-of-file marker. If ^C (Ctl+C or the Break key combination)
instead, the file is aborted and not created.
Some ASCII editors may strip the ending ^Z character, some add it,
some preserve it if it is there, else not.
You can't see the charaxcter unless you inspect the file in hex, but
the presence or absence of the end marker can affect how the batch
file terminates. For instance, in Win9x GUI, a missing ^Z causes the
..BAT to close the command window it is running in, even if the
Properties of the .pif are set to keep it open.
Batch files are interpreted a line at a time, i.e. being read from the
source storage a line at a time by the parser. That can be
significant if the last command is to destroy the batch file, or is to
complete after the batch file is no longer available (e.g. the
removable diskette containing the file has been sweapped).
If the last command is followed by an Enter character(s) and then ^Z,
the interpreter will try to find the next line after what is the last
one, which may hold the file open so that it can't be deleted, and
will cause a prompt to "insert the disk with the batch file".
To avoid these problems, it may still be elegant to lop off the
trailling Enter and ^Z sequence, so that the file unambiguously ends
(runs out of bytes) after the last command.
It may well be that an issue regarding ^Z is what is causing adverse
mileage. Even when not using the very powerful new extended batch
file sysntax (and really, if you don't need backward compatibility,
you really should check it out - it's ugly syntax at times, but oh
what it lets you do are things you'd dreamed of in DOS), there are
significant differences in the way NT (e.g. XP) and Win9x run .BAT
These differences are usually consistent whether you use the new NT
CLI (Cmd.exe) or the old "DOS" one (Command.com), i.e. you cannot
force pure Win9x-like behavior by:
- specifying Command.com as interpreter, e.g. Command /C YourBat
- forcing suppression of NT syntax extensions
Differences I have noted, include:
- batch files simply exiting midway through for no reason I can see
- now defaults to closing command window when done
In addition (and this is a compat killer!) undefined %varables% are
handled differently (you may be able to force the old handling by
forcing old syntax by launching a new instance of the CLI with the
appropriate CLI option - RTFM/search for details)
In Win9x, an undefined %variable% would return the nul string, so you
could do tests like If "%variable%"=="" etc.
In XP, an undefined %variable% returns the %variable syntax as a
literal, so that "%variable%"=="" would be as false as if the variable
was defined (inevitably, to a non-null value). You are supposed to
explicitly test for undefined state (If Undefined variable....), and
that isn't backwards-conpatible because Win9x CLI doesn't accept the
Undefined keyword and will do a "Bad command or filename"
BTW, the new NT syntax includes multi-statement lines (using a "join"
character) and parentheseis so that logic-flow blocks can span
multiple lines, e.g. something like this...
If "%variable%"==""" (
Blah
Blee
Bloo
) Else (
Flee
Flo
Flum
)
...but there are two ass-biters here:
- statements containing ( or ) prang the logic
- some contexts require 1 and only 1 statement (e.g. For ? )
and you are satisfied that batch files are not dead under
WinXP but are far, far more powerful than they ever were
Deffo. The new scripting languages add an extra layer of programming
complexity (e.g. defining stuff before use) that is new to batch
programmers, plus you may wish to suppress scripts for risk management
purposes, so you may want to use use .CMD (an alternative file name
extension for batch files) and the new syntax within.
BTW, either generation of syntax can be used in either .BAT or .CMD,
but because Win9x generally doesn't associate .CMD as batch files, I
prefer to use .BAT for old batch files that are syntactically and
otherwise compat with Win9x and .CMD for those that aren't.
The new syntax lets you:
- have multiple statements on a line
- have multiple lines in certain logic blocks
- adds an Else section to If
- lets you prompt for keyboard input
- lets you derive file spec elements from %parms and %vars%
- lets you read file size, date etc. from %parms and %vars%
- lets you search for a path element in a %variable%
- supports some basic arithmetic
- supports some string slicing operations
- lets you Call into the same batch file (crude subroutines)
- vastly extends the power of For in various ways
There's prolly more, but that's what I've made use of.
--------------- ----- ---- --- -- - - -
Tech Support: The guys who follow the
'Parade of New Products' with a shovel.
