 The magazine of the Melbourne PC User Group Redirection Tom Coleman |
 |
Last Month's Random Access column had a question about getting the system date into a batch file for use in a test. The answer referred to an article in PC Magazine. It did not demonstrate the answer.
It is worthwhile exploring this a bit further as it leads to all kinds of innovative uses of DOS commands for purposes that the authors lid not intend. Let's take a look at using redirection to input a date to begin with.
DOS commands (often they are just little programs that do a particular job) usually produce some kind of displayed output during or at the end of execution. For example the DIR command will produce lot of text about labels and so on even if the bit you were interested out turns out to be "File Not Found".
Similarly the DATE command gives you the date, which often seems to be 1-01-80 even when it is not.
This output is sent to the screen unless you tell DOS to send it
somewhere else. Telling DOS where to put its output is done by redirection with the > symbol.
DIR > PRN
will redirect the output of the command to the printer so you get hardcopy.
DIR > XXXFILE.ZZZ
will direct the output to a file called xxxfile.zzz. You can call the file anything you like. File.dir or Horse.nag or anything you please.
DATE > DATEFILE.TXT
would store the output of the DATE command to
datefile.txt. Again, any filename that pleases you will do. It need not have an extension
and could be one letter long. How about D thus :-
DATE > D
I like that - I will use it and save a bit of typing. I now have a file called D that has the date in it.
That's almost true. The DATE command requires that you supply a new date or press ENTER to accept the date suggested by the output. You must therefore press ENTER or input a date but as the output has gone to a file you have no idea of what the suggested date is until you read the file so you had best press ENTER for now. At least you will get your prompt back.
If you now give the command
TYPE D
the contents of the file called D will be printed to the screen. It will have all of the DATE command output including the suggestion to input a new date. Then redirecting the TYPE command
TYPE D > PRN
outputs the date to the printer. Probably not a particularly useful thing to do as it will only print it at the left margin on the
line where the printer head happens to be. That's without some more fancy
massaging, which I do not intend to go in to.
We could then use the FIND command to test the date. Is it oris it not Christmas Day. Now this is where you need to he very careful.
The FIND command is case sensitive and must be exactly right. Spaces, punctuation, upper and lower Case. letters must he exactly correct. What we are looking for must he placed inside quotes
TYPE D | FIND "25-12-1990"
would find what we want but that may not be very useful either, unless we were just looking for a one off confirmation of the Christmas Day status.
Note the use of '|' character, which DOS uses as the Pipe or Filter redirection symbol. It gets to be much more interesting if we redirect the output from the FIND command to yet another file which I will call DATEFIND. You can call it what you like.
TYPE D | FIND "26-12-1990" > DATEFIND
This command does a useful piece of housekeeping. It stores the line with the date on it in the file DATEFIND but nothing else, so it loses the clutter about putting a new date.
Here we encounter a new phenomena. If it fails to find whatever is between the quote marks, "26-12-1990" in this case, the file DATEFIND is created anyway, but it has no data and is a zero length file.
Do a DIR DATEFIND and you will see that the file size is 0 unless it has found the date. Then it is just a few bytes long.
At a more technical level what has happened is that DOS has put the file name in the Directory Area but as the file has no data nothing has been written in the data area. In other words no clusters have been allocated to the file. This explains why DOS cannot copy a zero length file. There is nothing to copy. That then gives us a way to test if it is Christmas Day. If it is not Christmas Day then DATEFIND will be zero length and cannot be copied.
COPY DATEFIND DDFF
attempts to copy DATEFIND to a file called DDFF which will be created only if the COPY command is successful.
DIR DDFF
will give a "File not found" message if DDFF does not exist or will display its directory entry if it does exist.
There has got to be an easier way of knowing if your computer thinks it is Christmas Day or not.
And so there is. You put it all in a Batch file.
| ECHO OFF DATE < CR | FIND "26-12-1990" > DATEFIND COPY DATEFIND DDFF IF EXIST DDFF GOTO XMAS ECHO EVERY DAY IS NOT CHRISTMAS DAY GOTO END :XMAS ECHO IF YOU DID NOT HAVE YOUR STOCKING OUT LAST NIGHT ECHO YOU HAVE BLOWN IT FOR ANOTHER 12 MONTHS :END |
The second line of the batch file is where all the action is. It reduces the number of steps shown in the preceding discussion by eliminating the intermediate TYPE step and introduces a bit not seen before. That's the CR part of the line. The significant thing about it is the preceding <169. "But what is CR" I hear you ask.
Remember that the DATE command requires some input, either in the form of ENTER or a new date. CR is a file you must create to supply ENTER to the DATE command otherwise the batch file will suspend execution waiting for the input to the DATE command. Here is the quick and dirty way to create CR
| COPY CON CR (press ENTER) (Press the ENTER key again) (Press F6 then press ENTER) |
What you have done is create a file called CR that has a single press of the ENTER key as its data. The F6 makes the End of File signal for DOS to know that that's all.
As the file CR is a data file it must be in the same directory as the batch file.
The batch file uses the FIND command so the file FIND.COM must also be available to it. However FIND.COM is an executable file and so may be in the PATH if it is not in the same directory.
Reprinted from the October 1990 issue of PC Update, the magazine of Melbourne PC User Group, Australia
