On 11/5/05, Ruud H.G. van Tol <rvtol(_at_)isolution(_dot_)nl> wrote:
I don't follow this. How is using a :0p (to switch over to PCRE for that
recipe) reducing efficiency?
It neither the switching, nor the mechanism for switching, that's the
issue; it's the implementation of the regex matcher itself.
My original point was that simply linking procmail against a
freely-available PCRE library is not an ideal solution, because it
is likely to result in a less efficient scanner. The library regex
engine is almost certainly optimized for different purposes than the
one for which procmail recipes would most frequently use it.
BTW, the PCRE is suggested as an enhancement, not as a replacement.
But unless it either replaces or is in some way combined with the
existing procmail regex engine, you end up with a binary containing
two complete and distinct regex engines. That's just silly; procmail
is intended to be a relatively small and lightweight program.
Could you illustrate your point with some examples?
Not entirely, because to do so would mean comparing regex
implementations at the source code level. However, your own example
is somewhat illustrative:
procmail: * ^Subject:(.*\<)?\/.*
PCRE: * ^Subject:(?.*?\W)?(.*)
Just look how far out of your way you had to go to coerce PCRE into
emulating procmail's semantics. Do you think most users would bother?
Do you think PCRE has been optimized for that usage? Do you even
think that the majority of procmailrc conditions in the world require
the \/ operator?
Incidentally, the problem with a PCRE=on type switching mechanism
rather than :0p is illustrated by:
PCRE=on
INCLUDERC=some_old_procmail.rc
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail