Re: thoroughput estimation

David Hunt suggested to Andrew Vardy,

|       :0
|       * (folder-delivery criteria here)
|               {
|               LOCKFILE=folder$LOCKEXT
|               :0 hic
|               |expr `cat file 2>&-` + 1 2>&- >file||echo 1 >file
|               :0
|               folder
|               LOCKFILE=
|               }

There's a problem with David's idea: most shells will clobber the file when
they see ">file" before forking expr or cat, so cat will always find the file
empty, expr will always have a syntax error, and the file will always be re-
written with "1"; besides, we don't need to fork expr or cat.  The trick is
for the file to contain a variable assignment (such as "OLDTALLY=15") instead
of just a number.

Also, because (1) in 3.11pre7 LOGABSTRACT=all has some quirks about logging
the delivery of copies to pipes and (2) in case the system goes down it's
probably more critical to store the message than to increment the tally,
I've changed the sequence to save the message first.

        :0
        * (folder-delivery criteria here)
        {
                OLDTALLY # make sure it goes in unset in case the same
                         # variable name was used earlier in the rcfile
                LOCKFILE=folder$LOCKEXT

                :0c # regional lockfile in effect, per David Hunt's code
                folder

                INCLUDERC=file # gets value of $OLDTALLY

#       If the includerc was missing or empty, or the value was corrupted,
#       start over from 0.  In fact, throw in the case where it's
#       legitimately 0.

                :0 # Reject any value other than positive integers.
                * ! OLDTALLY ?? ^^\+?0*[1-9][0-9]*^^
                { NEWTALLY=1 }

                :0E # If the old value is usable, increment it now.
                * $ $OLDTALLY^0
                * 1^0
                { NEWTALLY = $= } # Yes, inside the braces this time.

                :0 hi # one shell invocation, yes, but no expr or cat
                | echo "OLDTALLY = $NEWTALLY" > file

                # Procmail should never reach this point, but just to be
                # clean, let's release the regional lockfile explicitly:
                LOCKFILE
        }

As with David's suggestion, you can reset it by deleting the tally file,
truncating the tally file to zero size, or editing it to read OLDTALLY=0.  I
suggest the second or third method, since the first will cause procmail to
report an error when message #1 of the next count comes in, though the file
will still be properly re-written with OLDTALLY=1.