Paul Bartlett wrote,
| THEDATE=`formail -zxDate:` # When was it mailed?
| WHOFROM=`formail -zxFrom:` # Whom did this request come from?
| THESUBJ=`formail -zxSubj:` # What is the subject?
If your version of procmail is recent enough to include extraction, is it
much more efficient for that application than all those forks of formail.
Another consideration is that virtually no piece of mail has a "Subj:"
header (it's "Subject:" in my experience), so you must almost never find
a non-null value for $THESUBJ that way.
Anyhow, this is a much better way:
:0
* ^Date: *\/[^ ].*
{ THEDATE=$MATCH }
:0
* ^From: *\/[^ ].*
{ WHOFROM=$MATCH }
:0
* ^Subject: *\/[^ ].*
{ THESUBJ=$MATCH }
If your verson of procmail does not include extraction but does include
variable capture, at least you can reduce the load of those forks by loading
only the heads onto their tines:
:0h
THEDATE=|formail -zxDate: # When was it mailed?
:0h
WHOFROM=|formail -zxFrom: # Whom did this request come from?
:0h
THESUBJ=|formail -zxSubj: # What is the subject?
And if your version of procmail isn't recent enough for variable capture,
it isn't recent enough for scoring or braces or clones either, so the rest
of the code wouldn't be working.
| # Get message size
| :0HBc # note trailing period in first condition line
| * 1^1 .
| * 1^1 ^.*$
| * -1^0
| { }
| THESIZE = $=
As Philip Guenther explained, the `c' flag is causing the problem. You
don't want it there. It spawns a clone procmail, and since the code in
the braces doesn't result in delivery, the clone stays alive past the
right brace and you get two deliveries: one from the clone and one from
the parent.