Gary wrote,
| Alternatively:
|
| formail -ds procmail DEFAULT=`pwd`/. /dev/null < mailbox
Besides losing the zero-padding (which you might not want anyway, and which
in my example could be dropped by just starting FILENO with a single-digit
value), you'll make procmail figure out what the next available number is,
and that takes time, since each procmail has to sniff around the current
directory and see which existing number is the highest, and as I remember
that's generally more time and effort than getting an uncontested local
lockfile. I'd think it's much faster for formail to increment FILENO and
procmail just to use it. Moreover, if you use formail's -n switch with it,
| Since operations on the mail directory are implicitly locked,
| we can safely use formail's -n switch to achieve additional throughput.
That can lead to a problem. By not serializing the procmail calls, you can
get messages stored out of their original sequence: that is, the fifteenth
message from the input might get file #14 and the fourteenth message file
#15. That may or may not matter to the given user on the given occasion.
But with
FILENO=1 formail -nds procmail -p DEFAULT='$FILENO' /dev/null < mailbox
that won't happen, because even if message #15 is written before message
#14, the filenames will show their original sequence.
Also, in my own testing, using -n with MH-style folders or with saves to
$FILENO led to a massive hang where procmail didn't get all the way through
on the last few dozen messages.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail