Batch Sequential Processing of a List
By repetitively processing and stripping the first
line in a list, the entire list can be processed.
This is the "pure" way to use DOS to process an entire list. Very
disk-intensive.
Create a line fragment and put it
at
the head of your data file. The line fragment will be the name of your
processing batch file followed by a single space. Now your data file is
a batch file! After running it, you will have processed your first data
line. Now run the data / batch file through FIND to strip off the first
line, turning it back into a (smaller) data file again. Then add your
line
fragment again (turning it back into a batch file) and re-run it, this
time processing the second line. Keep doing this until all lines are
processed.
As an example, suppose we start with this:
|
FRAGMENT.TXT
|
DATA.TXT
|
MAIN.BAT
|
PROCESS.BAT
|
| PROCESS.BAT |
data1
data2
data3 |
@echo off
:START
copy FRAGMENT.TXT + DATA.TXT DATA.BAT > NUL
call DATA.BAT
type DATA.BAT | find /v /i "PROCESS.BAT" > DATA.TXT
dir DATA.TXT | find " 0 bytes" > NUL
if errorlevel 1 goto START
:DONE |
echo Processing %1 |
The "fragment.txt" has a space at the end of the word, but no
carriage-return. For example "PROCESS.BAT " (but without the
quotes). You'll see later why it's needed.
The "data.txt" is your data! Keep in mind, this data file will be
trashed by the batch file. You may want to copy your real data source
into the "data.txt" file by sticking a copy command in the "main.bat"
file between the "@echo off" line and the ":START" line. Or copy it by
a separate process before running the "main.bat" batch file.
The "process.bat" is the file you'll put most of your effort into. It
will be called several times, getting an entire line of "data.txt"
passed as an argument. It will be up to you to something more
productive than simply echoing the value to the screen like I'm doing!
Here are the tricks in "main.bat". First off, everything gets
redirected
into NUL to keep the screen clean. The initial COPY command will result
in a "data.bat" file that looks like this:
PROCESS.BAT data1
data2
data3
The space separating PROCESS.BAT from data1 is because of the space in
the original "fragment.txt". Now you see why it's needed!
When the DATA.BAT we just created is CALLed, it will in turn run
PROCESS.BAT, passing
"data1"
as the argument. PROCESS.BAT, in turn, will display "Processing
data1" on the screen. Because DATA.BAT "runs" PROCESS.BAT
(instead
of CALLing it), control will *not* return to the second line of
DATA.BAT
after PROCESS.BAT finishes. Instead, control passes back to MAIN.BAT.
Maybe it's a bit confusing about the difference between using "call" or
just running a batch file, but be happy that there is a difference!
That difference is what makes list processing under Win9x possible.
Next,
DATA.BAT is TYPEd through FIND to remove the first line. We now have a
DATA.TXT without the first line:
data2
data3
After removing the first line and creating a new "data.txt", we use the
DIR command to see if anything is in the "data.txt" file. If we can't
find the phrase " 0 bytes", then we have more data to process and we
start over. If we do find the phrase " 0 bytes", then we quit.
If FIND can't find the phrase, it returns an errorlevel of one. If it
does find the phrase, it returns an errorlevel of zero. Using
errorlevel testing is confusing because errorlevel tests are always
"greater than or equal to", so a test for errorlevel zero will
always be true. Because, you know, everything is greater than or equal
to zero! Practically speaking, you use "if errorlevel 1" to test for an
error and "if not errorlevel 1" to test for no error.
Lost? Look at the site map.
Bad links? Questions? Send me mail.