At 18:20 2005-11-05 -0800, Bart Schaefer wrote:
It neither the switching, nor the mechanism for switching, that's the
issue; it's the implementation of the regex matcher itself.
Uhm, two matchers seems fine. Not as efficient from a linking standpoint,
but why can't procmail be told to use a different regexp library?
My original point was that simply linking procmail against a
freely-available PCRE library is not an ideal solution,
I don't think anyone was suggesting that it would be "simply linked" - it's
a feature request. I need to plant my flag in the camp that says having to
invoke some external process to achieve something I _should_ be able to do
within procmail is preferrable. Each process you have to invoke to do
something seriously errodes at any efficiency losses introduced by having
two separate regexp libraries linked.
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.
Less efficient is a reasonable tradeoff for being able to achieve things
which you can't presently do, or which you have to jump through some major
loops to do.
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?
Hey, assigning MULTIPLE matches to $1, $2, ... would be rather useful at
times. Think of all the multiple match operations people have to do to
parse something out of a message...
Incidentally, the problem with a PCRE=on type switching mechanism
rather than :0p is illustrated by:
PCRE=on
INCLUDERC=some_old_procmail.rc
Easily dealt with by having the PCRE state revert with each
includerc. Push the state on the stack, reset it to OFF, pop it off when
the include completes. Hardly rocket science. Sure, there's going to be a
few people who get confused - "hey, I turned it on, but in the new rc, it
seems to be off". OTOH, just look at all the people who have to be
directed towards some clear statement in the manpages now...
I think it'd be a LOT more useful to discuss possibilities, even if there
may be implementation issues, rather than to shoot them down.
FTR, one could have an engine revision line as a pseudo comment at the head
of the rcfile, and procmail could be made to run rcs in much the same way
as shell scripts do.
Heck, have procmail operate using different semantics depending upon the
filename under which it was invoked.
procmail (classic syntax)
procmailx (advanced syntax)
That can also be a way to skirt some compile issues - either you HAVE the
new version, or you don't.
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail