At 11:02 2002-10-16 +0700, Robert Nicholson did say:
Why is it inconceivable that you'd want to in addition to returning a
value also filter?
It isn't inconceivable. You were complaining that your recipes weren't
paying attention to the filter because you were running your program as a
CONDITION operation. I pointed out that it was because you're not invoking
it as a filter.
Procmail has flags (see 'man procmailrc') for whether it ignores write
errors (the delivered-to _filter_ not reading the entire message) or
whether it waits for the message filter to complete AND pays attention to
the return value or ignores it -- if you set up your filter to return an
error value when it decides that it DOES NOT need to filter, and success
when it does, then procmail can disreguard the filtered output on error.
Of course, if the only thing you're doing is adding another header, if the
filter always outputs everything - either with, or without that extra
header, then there isn't a great deal of need to return a success/fail
value, except perhaps as a slight performance improvement.
My filter shouldn't have to be responsible for mail delivery ie. writing
the message into a mailbox. That's procmails job so what I'm seeking is a
way to conditionally tell procmail to write the mail to the designated
mailbox but in addition also be able to change the message content.
:0Wf
| /path/to/yourfilter
:0a:
some_mailbox
'a' means that the previous recipe must have been successfully completed.
'f' means to filter (change it and continue processing using that changed
version) the message.
'W' suppresses program failure messages, but waits for the filter to
complete and considers the message UNFILTERED (that is, ignore the filter
output and stick with the original message) if the invoked filter program
returneds an error.
$Headers, $Body are defined in another file.
RFC says that Headers ie. Mail Headers are separated from the Body by a
newline.
The last line of the $Headers isn't terminated by a newline.
Which I guess is a function of how you parsed them. Might I suggest adding
a newline to the neaders right off when you initially parse them, and in
your filter, appending the new header line to the headers:
$Headers .= "newheader: content\n" ;
or:
$ExtraHeaders .= "newheader: content\n";
(for those coming into this late or from the archives, that's for an
external PERL recipe Robert wrote.)
Set a success flag, and exit your filter from the main function (not
presented to us) so that the $Headers\n$Body (or,
$Headers$ExtraHeaders\n$Body) is emitted IF the success flag is set. This
would allow you to have MULTIPLE filtering operations going on, and any one
of them could add different headers.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail