procmail
[Top] [All Lists]

Re: repeat limited regexp?

2002-08-20 15:26:45
You are correct.  However, I was mainly thinking of a single revision
grace period.  The command line option would exist for that purpose, only
until the following upgrade, at which point it would either provide
someother backwords compatability, or not doing anything.  Just enough
time to allow people to make the transition, and test their code in the
process.

Luke


On Tue, 20 Aug 2002, David W. Tamkin wrote:

Luke proposed,

| Actually, that could be fixed with a variable:
|
| LEGACY = yes
|
| If set to yes, the default if unset, braces need to be escaped to function
| as multiple match controls.  If set to no, it would function the other
| way.

I see a major problem with that: every extension or addition to procmailrc
syntax would need another such variable.  It's not as if nothing had changed
before: the way to request a local lockfile has changed since I started using
procmail, and things such as brace nesting, asterisk notation, several
colon-line flags, cloning, extraction into MATCH, filtering recipes,
positional parameters set by -a or -m on the command line, variable capture
recipes, exit code conditions, $\VARIABLE substitution, variable and command
substitution of regexp conditions, scoring, multi-line matching, specifying
the search area for a condition, word-bounding wildcards, tokens like ^TO and
^TO_ and ^FROM_DAEMON and ^FROM_MAILER, and who knows what else I can't think
of right now, have been added.  Each was done in a backward-compatible way by
utilizing notation that previously had been invalid or silly.  If they had
been done by changing the meaning of previously valid code, there would be a
stack of LEGACYx variables by now, and nobody could keep track of which
upgrade went with which variable.

It's not as if procmail rcfile syntax had never changed before, will change
just this once, and never will change again.  To introduce LEGACY now would
mean that every future change would mean reserving another such variable, and
that there would be some point (namely, today), before which setting or
unsetting these variables could not make procmail go back any further.  It
would also mean that every future release of procmail would need to know all
the different features from today on to turn off for each of those accumulated
variables so far by the time it comes out.  That's a lot of extra code.

It would also create a problem for people already using LEGACY as a variable
in their own rcfiles, but since procmail has co-opted other variables in my
time, I guess that's acceptable.

| The same could (probably better) be accomplished with a commandline option.

That is, with a panoply of command line options, one for every rcfile syntax
upgrade since the dawn of procmail, or at least since today.

Erik has a point that this would be the watershed where procmail diverges so
far from egrep and perl that the procmailrc(5) man page should use a different
modifier instead of "extended" regular expressions; perhaps it's already gone
over the line with the existing differences.  But sorry, Luke, I strongly
disagree with your suggestion.





_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>