Dallman Ross wrote:
To wit, let's take this example recipe:
:0
* 200^0 ! ^From:
* 100^0 ! ^Message-ID:
* ^^From ()
* ^Date:
* ^Received:
{ WE_ARE_HERE }
We know looking that if both the first two conditions fail to match,
there is no point in going on. Even if the bottom three are true,
the recipe will never get to WE_ARE_HERE. But procmail doesn't
know that. (Bart knows it; don't take this as my attempt to teach
him.)
That's because procmail doesn't read ahead and then back up; procmail
does not know, after the second condition, that there are no more
weighted conditions coming up, just as immediately after the first
condition it didn't know that there would be another weighted condition
to come.
This does bring up a question, though, the answer to which I don't know:
Since From_ is always above Date:, are we making procmail do extra work
by starting with a test of Date: and then moving "upstream" to From_?
My understanding is that procmail rescans the search area for each
condition, so the answer is no. It will start from the beginning for
both of them (unless a mismatch on the earlier one makes it skip the
second condition altogether), rather than holding its place and looking
from that point (only perhaps to need to wrap around to the beginning
anyway).
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail