Re: Suggestion for Enhancement; B, H, ... and D

At 18:13 2002-02-16 -0600, David W. Tamkin wrote:

> Sean, you're looking at it backwards.  Yes, an older binary can't handle the
> new syntax; that's inevitable with an upgrade.  The problem is that a newer
> binary will misinterpret the old syntax, and we can't allow that.  What if
> someone has a regexp that ends with "/D" because the search pattern ends in
> slash-D?
Let me clarify: I wasn't saying that the "/D" was necessarily 
LITERAL.  Merely that tacking some sort of flag at the EOL might be the way 
to go, since it wouldn't cause variable ambiguity at the BOL.  The problem, 
as I alluded to, is that even if earlier procmails don't puke on the syntax 
and instead just return FALSE for the regexp, they'll return TRUE when you 
INVERT the condition, which will lead to troubles, thus, silent syntax 
failures with pre-extension procmails isn't really a desireably trait - 
people won't immediatley be alerted to the fact that the recipe isn't going 
to work as expected (of course, everyone thoroughly tests new rulesets in a 
sandbox before making a ruleset live, so this shouldn't be a problem, 
right? <g>).
> Yes, I understood that part; I was just also wondering how much already is
> inside the box in order to gauge how much priority such a project should
> get.
Heh, I never said the project should have any priority. <g>

> | Similar to E, what about an OR clause (ignore choice of specific letter
> below):
> |
> | * ^From:.*something
> | *+ O + ^Reply-To:.*somethingelse
>
> No, you can't put "or" onto some conditions and leave "and" implicit on
> others, because then there are questions of grouping.
The first element following an or which DOES NOT have an or flagging 
becomes the next AND:
* B ?? something
*+ OB + ?? somethingelse
* B ?? whatever
*+ OB + ?? somename
*+ OB + ?? someword

Would group as:

(something || somethingelse) && ( whatever | somename | someword )

Certainly, no advanced grouping constructs, but then, you can do those from 
grouped/chained recipes.  I think primarily the facility of having a 
separate condition line which can be simply or'ed would assist a LOT of users.
> An ORing flag on the colon line would be nice,
Indeed, this should probably be added at some point then.  With it, you could:

:0
* somerequiredcondition
* anotherrequiredcondition
{}

# or ('|') flag not ACTUAL valid flag at current time - this is merely an
# example for discussion.
:0A|
* orcondition
* orcondition
* orcondition
* orcondition
realaction

As already indicated, this cam be accomplished from within a single scoring 
recipe:
:0
* somerequiredcondition
* anotherrequiredcondition
* 2147483647^0 orcondition
* 2147483647^0 orcondition
* 2147483647^0 orcondition
* 2147483647^0 orcondition
realaction

> but it makes no sense on individual conditions.
I don't fully agree, but that's only on the basis of making the rules 
perhaps a bit less involved when someone wants to accompish something 
requring some conditions and one of several others.  I merely put it forth 
as a potential example of the type of thing which having a line condition 
based flag might be useful (consider that B and H could be used in chained 
recipes instead of also being useable as special variables - but having 
them as special variables makes recipe-writing easier and ofttimes clearer).
I'm merely playing devils advocate here - I don't have an immediate need 
for the case sensitivity switching which Michael is asking for, and this OR 
thing would merely be handy here and there.  I'm just tossing out some ideas.
> There is no efficiency problem if you use supremum weights in the right
> places, or if you use the double-reverse DeMorgan trick.  I posted about
> that to procmail-dev a couple of months ago, and no one had any comment.
As I recall, you posted it on procmail-users as well, or at least some 
questions about it.
> But maybe the question here, when all is said and done, isn't yet about
> opening a portal for extensibility but so far only to define a way to make
> individual conditions case-sensitive or case-insensitive.
Flags for on and off within the expression remain my favourite 
candidate.  What I'm arguing is that _IF_ an additional flag is considered, 
something should be done to allow extensibility in the flags 
definition.  This could very well be applicable to future dealings with 
MIME, as an example.
---
 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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail