On Sat, Feb 14, 2004 at 12:32:35AM +0100, Kai Weber wrote:
I don't understand the procmailrc manual what it is saying on the w flag:
"Wait for the filter or program to finish and check its exitcode
(normally ignored); if the filter is unsuccessful, then the text will
not have been filtered."
What does "then the text will not have been filtered." mean?
When the man pages talk about a "filter," they mean the use of the "f"
flag to a recipe, which is a special case. Don't be confused by the
generic use of the term "filter," which many people use with undue
casualness to mean a procmail recipe in general (because it does, after
all, "filter" one's mail in the manner that a seive or grate filters
things poured through it).
The "f"-flag one recipes turns them into non-delivering recipes. So
processing continues when the recipe is over. Consider this:
:0
| formail -A "X-Loop: me(_at_)mydom(_dot_)com"
That will "eat" the mail, because it is a delivering recipe. We put the
"f"-flag in place, though (almost always with a "w" or "W" flag), and
it now is a "filtering" recipe. The header gets added, and processing
continues below. Here it is correctly expressed:
:0 fw
| formail -A "X-Loop: me(_at_)mydom(_dot_)com"
I think of filtering recipes as "function boxes." Put something in one
side, and a transmogrified something else comes out the other side.
The man page is a bit hard to fathom in that section. I propose
that the main reason is that in the Olden Days there weren't as many
pipes being run from procmail, and the few that were, were almost all
filtering ("f"-flag), non-delivering recipes. So the whole discussion
of "w" or "W" is now sort of inexroably bound up with the "f" flag.
And because people are prone to use "filter" in the English sense rather
than just the procmail sense, things do get awfully confusing, awfully
fast.
The answer to your question, then, is that if you are using an "f"
flag for a non-delivering recipe -- it is virtually a _sine qua non_
that a "w" or "W" flag will be used there too -- and if the exit code
shouts "Error!" then procmail will back out of the "filter" changes
and send the original message from stdin onward for processing through
the remaining recipes or assignments below. (And you'll see an error
message about it in the logfile.)
Since the attempts we've been making with clamscan are not filtering
recipes, though, that text is not precisely applicable, at least
as worded. Bart was just questioning or that wording too, in
his very recent message, but I'm not entirely persuaded by his
stated conclusion.
Hope that helps.
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail