I've seen several similar inquiries in alt.msdos.batch recently to the one show below.

I started a response to this particular post, but realized just how immense a problem this is to handle in batch. Poor Wayne really had no idea what he was asking. He has obviously never tried to perform any math in a batch procedure or he'd know just how hard it is to "check to see if there is a difference of more than 10". Especially, when it comes to doing that with a date string!

Well, I decided to accept the challenge and this new article is the result. It actually covers two subjects: 1. Making a date derived file name and sifting a file listing based on a cuttoff date. Note that this is NOT intended for use with NT.

BTW, folks, I don't do courtesy Email responses to anti-spam addressees. I spend too much time answering questions as it is. I'm just not going to take the time to patch up an adulterated address. Don't get me wrong, I sympathize with you're plight, but I just can't deal.

First, here's my latest code for parsing the current date on a DOS/Win 95/98 equipped machine ...

If UnidateC.bat is called without any arguments, it returns the parsed date in three default (object like) variables: Date.MM, Date.DD, Date.YYYY. These can then be used to rename the file, something like ... call unidateC ren %Date.MM%%Date.YYYY%.log %Date.MM%%Date.DD%%Date.YYYY%.* Or the routine can be called with one argument to name the 'object' (e.g. call unidateC Obj => Obj.MM, Obj.DD, Obj.YYYY).

The routine should work regardless of country language or date format, though I have not been able to test it in ALL environments ;-)

To get a glimmer of an idea of how the procedure works, try typing the following at a command prompt and reviewing the result ...

rem > {A} echo 08/11/1999Y| del {A} /p The procedure uses the output of a similar DEL statement to do the parsing and two temporary batch procedures, {A}.BAT and {B}.bat, to collect the parsed pieces.

Now if you think UniDateC.bat is hard to understand, I better warn you that the other part of the job is just as hard, or harder.

The approach I recently developed uses a 'flag' batch file which has two lines in it ...

set RemoveDate=08/09/1999 set Yesterday=08/10/1999 This batch file needs to be constructed once, manually. After it's creation, the cleanup process incements each date until the 'Yesterday' variable equals the current date, using the following routine ...

IncrDate takes one optional argument: a string NAMING the variable which contains the date to be incremented (not the date string). If no name is given, today's date is incremented by one day and stored in the variable 'Tomorrow'. Note that IncrDate.bat IS country language dependent. It assumes the output of the DATE function begins with the word 'Current' and that the first line of output has exactly four words preceeding the date string. The temporary batch procedure, Current.bat, must be adapted accordingly to accommodate other language versions of DOS/Windows.

Beside this limitation, IncrDate, manipulates the system clock, causing it to run a tiny bit slower for each call. This shouldn't be too much of a problem as PC clocks are not known for their accuarcy, anyway.

There are still two more procedures necessary to fulfill the requirement of deleting files based on date: a procedure to oversee the whole process and a date search procedure. I think I'll cover the oversight procedure before getting to the date search . It's a bit simpler.

The oversight routine, shown below, reads the current date, the dates in the flag file, calls IncrDate.bat to adjust the dates and calls the file search procedure to act on the files created before the appropriate date.

Cleanup.bat takes one optional argument, the name of a folder/directory to sift. Note that the flag file, c:\_dates_.bat MUST exist before executing Cleanup.bat. It will be updated automatically upon completion of the Cleanup process using the IncrDate.bat procedure. The updating of the variables takes place before processing the files, but the '_date_.bat' file is rewritten after the process is completed. This acts as a flag for completion of the process. Subsequent calls to Cleanup on the same day results merely in a message declaring that the cleanup has already been run. Note that the date incrementing loop is repeated until "Yesterday's" date becomes "Today's" date.

A simple string comparison is used with no error checking. This is sufficient as long as care is taken in constructing the '_dates_.bat' file the first time to insure that the date formats are valid and that "Yesterday's" date is equal to or less than the current date at the time it is first run. IncrDate has error checking code to check for valid date formats, but there is no check that Yesterday's date is less than or equal to Today's before the procedure runs. If a date later than the systems currently set date is written into _dates_.bat, the Cleanup procedure will enter an infinite loop.

Finally, the routine that does the actual sifting of files, based on the criterian date.

DSearch.bat works by adjusting the system date to the value stored in the environment as RemoveDate, writes a flag file, {1}, in the current folder, restores the date to Today's date, creates a file listing sorted by date and processes that list until the name of the flag file (or the end of the list) is reached.

DSearch takes one optional argument: the name of a process, program or command. It runs that process once for each file name on the list.

What's left to do? Put all of the procedures in a directory/folder named in the PATH and add a call to the Cleanup.bat procedure in your AUTOEXEC.BAT (DOS/Win 95/98) or in the "C:\Windows\All Users\Start Menu\Startup" folder (Win 95/98). Or, call it manually when desired.

Well, I said the solution was immense, didn't I? I'll try to tweak the procedures and expand the explanation of their function over the next days. It might be worth a check back here sometime, if you're interested, but I can't guarantee anything.