procmail
[Top] [All Lists]

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

2002-02-19 15:31:09
Erik asked,

|    To gain per-condition case sensitivity, would it be completely silly to
| do something like:
|
|    :0:
|    D * ^From procmail-admin
|    procmail_u

As long as you want to speak in terms of silliness, then yes, it would be
very silly indeed, because it's incompatible with procmail's continuing to
understand rcfiles written before the days of the asterisk.  With another
asterisk before the D as you used later, it might work.

|    To have any chance of winning over the proponents of "funny regex",
| procmail's missing {n,m} functionality would probably need to be added to
| the limited * and +. i.e.:
|
|    [A-Za-z]{3}    # Exactly 3 case insensitive characters
|    [A-Za-z]{3,}   # 3 or more case insensitive characters
|    [A-Za-z]{,4}   # Up to case insensitive characters
|    [a-z]{3,7}     # 3 to 7 case sensitive characters

Not nearly so silly as the former, but still somewhat, and the reason is the
same.  If a range of how many matches to allow is ever implemented, the
braces will have to be backslash-escaped to avoid misunderstanding older
rcfiles where a brace meant a brace.  If you'd escaped the braces, then I'd
be all for it.  For one thing I can never remember which is the better way
to write this stuff currently.  Philip has often explained why, for
a\{3,\7}, it's not efficient to write

 aaaa?a?a?a?

but I can't for my life remember which way he says is best.  Is it

 aaa(a(a(aa?)?)?)?

I think?

| Wouldn't mind a new flag to OR instead of AND,
| though, to echo a previous poster. It could perhaps go in with the
| per-condition case switch:
|
|    * D O * ^frog[a-zA-Z]{3,7}      <- Case sensitive, OR, with insensitive
|                                       part.

No.  You can't mix ANDs and ORs without some sort of grouping.  I'd like to
see a way of setting ORing on the colon line for the entire recipe [rather
than using supremum scores or an inverse DeMorgan rule], but if you want to
AND some conditions and OR others, you need a way to specify grouping.  I've
already said that in response to Sean, who replied that ORs should always
take precedence over ANDs and that we should split recipes up into chains or
nests when that isn't what we need, but I'm not so sure that that is the
best choice for a default way to mix ANDs and ORs.  There's no way to guess
what a user has in mind if procmail allows mixed ANDs and ORs without
grouping, and any hardcoded default is likely to be wrong almost all the
time.

Now if someone wants to propose a way to mix ANDs and ORs among the
conditions on a recipe that includes specification of grouping, I'm all
ears.  But forcing an arbitrary precedence is no better than what we have
now except for the occasional cases where the user's desired precedence
chances to match it, and ignoring the issue of grouping just shows that one
hasn't thought the idea through.

|    Look! Clean EREs.

Where?  Those in your post look pretty darn messy to me.

DWT

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