At 20:26 2005-11-05 -0700, Google Kreme wrote:
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.
No, this is NOT the way to do it. if it's turned on, it's turned
on. if you screw up and turn it on before loading a old style rc
file, well, that's your mistake.
Look at it from a different perspective: if an RC contains code that is
intended to use the newer style regexp, why SHOULDN'T it just have a
PCRE=ON setting at the top? Then it would work when included by other
rcfiles without having to rely upon some prior file having set up the
universe correctly for support of the syntax. In this fashion, having a
PCRE flag which acts in a FIFO stack fashion WRT includerc would make
perfect sense. includercs which don't explicitly set the PCRE flag would
be presumed to be using older syntax seeing as they didn't explicitly turn
PCRE on.
Overall though, a recipe FLAG is preferrable anyway. Even the :0 part of
the flag could be changed - originally, that was to indicate the number of
conditions which followed the flag line, then it morphed into :0 because
procmail could figure it out while parsing it anyway, and now, perhaps :1
or :2 (etc) would be suitable as a regexp or functionality level
specification. This has the added benefit that when relating a recipe, the
recipe itself shows the versioning needed. A separate PCRE=ON type setting
is likely to get forgotten somewhere along the line when discussing a
recipe as one poster gets familiar with discussing newer syntax, and
another user gloms onto it thinking it should work in their version.
Ideally, some setting which causes an older procmail to emit an error
should be used to indicate newer functionality is expected. That way,
users don't end up with silent failures.
There are a number of ways to go about it. I believe there's sufficient
user demand for PCRE support that it should be seriously considered.
---
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