At 21:31 2004-06-26 -1000, Michael J Wise wrote:
Using unescaped braces to specify the number or range of repetitions
conflicts with existing rcfiles where a brace in a regexp means a literal
brace character.
:0 as an "Old School" flag deals with that.
Great, so the new procmail still has to parse OLD procmail scripts. 'cept
that regexp lines differ. That isn't going to SIMPLIFY anything - it's
going the make the code that much more complicated for no good reason.
even if it had some way to recognize current-syntax flag lines, would
break old pre-asterisk rcfiles where a regexp condition begins with a
literal colon to match a colon.
Time to upgrade.
Not an option all users have. In fact, many users have bemoaned that they
don't have any control over the version of procmail they're using. If you
want to produce a version of procmail which IS NOT procmail compatible, go
ahead - but kindly call it something else, because a lot of newbies (which
presumably are the people who would benefit the most from such sweeping
changes) are going to become very confused if they see two different syntaxes.
Incompatible recipe syntax (opening, regexp conditions, and delivery)
pretty much make it an entirely different tool anwyay.
I carefully considered the idea of a plugin capability such that the
plugins would intentionally use a shelled program syntax, but have procmail
interpreting that the shelled program was in fact already loaded (or would
be loaded the first time and retained in memory for subsequent
invocations), so that the syntax would be backward compatible - so long as
a user had a program to be called with the same parameters, an older
version of procmail could call it without problems and still manage to get
the job done - though some advanced capabilities might be an issue (even
some of those could be attended to with a called program paying attention
to the PID of the calling procmail and pulling some tricks).
I'm not going to argue the rest of the points: drastically changing the
syntax of procmail would be a VERY BAD THING.
There's enough users who can't manage to comprehend the current procmail
recipe syntax correctly: what happens when there's a separate, incompatible
syntax, and whether it works for them AT ALL (not even with minour tweaks)
is a matter of what version of procmail they're running?
---
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