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