Michael Wise followed up,
You don't recognize the example instantly?
Of course I did. They were from the man pages as a way to save a backup
copy of every message. You wanted to show some currently valid syntax
that the proposal needn't break; it doesn't matter whether you used one
we'd all seen before or one you came up with on the spot. You made your
point of illustrating one valid form that could survive. My point was
that supporting one form from the current grammar is far from full
backward compatibility.
:0 as an "Old School" flag deals with that.
If you're suggesting, as Kreme has in the meantime, a delimiter that
means "switch to new syntax" and then one that means "switch to old
syntax," yes, that could work. Then if a currently valid syntax is
given a new meaning, the delimiters make it unambiguous; problem solved.
The mark for "switch to new syntax" could not be two colons as Kreme
illustrated, though; it would have to be something that's illegal now,
such as the two semicolons.
If you mean that ":0" would be an indicator to switch modes and use
old-school syntax until a "switch to new syntax" mark shows up, that's
something else. You had not said anything about coupling it with an
explicit switch-to-new-school mark; if that's what you meant, it changes
everything. Letting procmail know which mode it's supposed to read it
removes any ambiguity.
Of course, the new binary would have to be big enough to understand
both, but the old-syntax part would likely never change again.
"/" would start a condition.
That would not work in an old-school section, but in a new-school
section, do whatever you please.
... old pre-asterisk rcfiles ...
Time to upgrade.
Think about what you've just said. When it comes to a currently valid
form that you like, such as ":0", you demand that the new binary be
backward-compatible with it; but when it comes to a currently valid form
that you don't like, such as counting conditions instead of asterisking
them, you dismiss it as expendable and tell its users to change their
rcfiles to adjust to upgrade. You've made your perspective very clear.
Perhaps you missed the references to "+" and ">" in non-"Old School"
mode.
If you think I missed them, then perhaps you missed my discussing them
in my last post, where I said that condition lines that start with a
colon are not backward-compatible, but action lines that start with a
plus sign are not a problem, and that I'd need more information before
saying whether action lines that start with a greater-than sign are or not.
But delimiters that mark the transition between old-syntax code and new-
syntax code would obviate the whole thing. All that is required for
backward compatibility are (1) to default to old syntax at the top of
every rcfile and (2) to pick something illegal under the old syntax as
the "switch to new syntax" indicator.
On second thought, even #2 isn't necessary. Other versions of procmail
have introduced new reserved variables (such as INCLUDERC and SWITCHRC)
without concern that someone's rcfile might already be using them as
ordinary variables, so the switching could be done by assigning a variable:
PROCMAIL4=on
and
PROCMAIL4=off
But I get the feeling that, like you and Kreme, the designers might
prefer something like ";;" to switch to new and ":0" to switch to old.
Fine with 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