On Fri, 15 Feb 2002, David W. Tamkin wrote:
I'll even go farther and say that it would be nice to be able to specify
D on single conditions as well as a search area that isn't necessarily B
or H or HB or BH, or even on the default search area.
Yes. The problem with adding `D ??' is that it doesn't specify _where_ to
match, and it'd be unworkable to add all of DB, BD, DH, HD, etc. as magic
variable names. Also, what if one already has `D' in the flags and wants
to make just one search case-INsensitive?
There needs to be some other way to indicate it, and just about
everything is taken. Maybe starting the regexp with an unescaped plus
sign (which is to say, I suppose, a not-twice escaped plus sign), or
using plus instead of asterisk to introduce the condition line (not such
a good idea, I suppose)?
I think you're on the right track, but there still needs to be a way to
say "off" as well as "on". A single flag that means "toggle" is not very
desirable because you have to know the start state to know whether to use
the flag. Choosing syntax that is currently illegal (so that no working
procmailrc could be using it now) is a good way to add extensions in a
backwards-compatible manner, but it would push the regex syntax even
farther out of sync with grep et al.
Probably the right way to do this is to add a new flag, perhaps X, which
means that the condition lines for this recipe are to be parsed using a
new extended syntax. Then choose whatever syntax makes the most sense,
without worrying about whether it's backwards-compatible.
On a slighly related topic, is there some reason not to make B, H, etc.
into real variables, e.g. so that LOG="$HB" would dump the entire message
to the log file? I suppose then the question would be whether assignment
to those variables is equivalent to filtering ...
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail