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.
Right. Now please show me a procmail solution matching something to the
left of \/, and compare that with the PCRE solution - procmail is as
dead as anything you can imagine. Piecing strings together backwords one
by one character is all that needs to be said about this.
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?
You ask the wrong way round: how many real-world problems are there for
which the \/ procmail operator is completely useless?
Incidentally, the problem with a PCRE=on type switching mechanism
rather than :0p is illustrated by:
PCRE=on
INCLUDERC=some_old_procmail.rc
Yes, that's a problem. The other problem is that it's the third
millennium now, and procmail hasn't kept up. No mime support, gazillion
calls to test, sed, awk, you name it, no Nth header matching, character
set handling in headers - oops, ...
It's no doubt a great virtue to have small, lightweigth, efficient
software - but I have to ask myself whether this is secondary to getting
the job done in the first place. The cost of computing has gone through
the floorboards when compared with the cost of programmers and
sysadmins.
My 0,02$CURRENCY
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
____________________________________________________________
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