era eriksson <era(_at_)iki(_dot_)fi> writes:
On Fri, 18 Feb 2000 02:59:16 -0600,
Philip Guenther <guenther(_at_)gac(_dot_)edu> wrote:
era eriksson <era(_at_)iki(_dot_)fi> writes:
What I thought he was asking, after thinking the same thing you
apparently thought, was if there could be something less
cumbersome than recursive INCLUDERC=s and all that jive to look
for a multi-condition pattern. If there are many matches, Procmail
will grab the first, but perhaps it is the second one which would
satisfy your additional checks against MATCH. That sort of thing
is what I imagine this is about. (But I haven't really gone back
and looked at the start of this thread. Anyway, if that's not what
Ralph meant, consider this one of +my+ top items for the wish
list.)
Hmm, that sounds like "look ahead assertions", at least for the
case where the additional checks are regexps. Is that what you're
thinking of, era?
Not exactly. More like this.
:0R
* ()\/foo|bar|baz|quux
* $ $\MATCH.*($)\/foo|bar|baz|quux
* $ $\MATCH.*($)\/foo|bar|baz|quux
{ action }
The R flag here would mean, if the first condition matches but the
second doesn't, roll back and look for the next possible match for the
first condition, then repeat recursively until you run out of matches,
or the conditions are all true.
If I understand what you're saying, the above would be equivalent to the
current
:0
* (foo|bar|baz|quux).*$(foo|bar|baz|quux).*$\/(foo|bar|baz|quux)
{ action }
so I'm either missing something or your example was simpler than you
meant it to be.
The only interesting cases are when more than one set of requirements
are to be applied to a given blob of text when matched. For example,
"match a line containing both foo and bar". In some cases this is
expressible in a standard regexp ("(.*foo.*bar.*|.*bar.*foo.*)"), but
when the requirements overlap it can be difficult to impossible to
express in a single regexp without something like perl's lookahead
assertions, and if the conditions cannot all be expressed as regexps
then you need to find a way to tell restart the matching, skipping the
one that was returned.
This particular case could of course be solved with lookahead, but I
believe it shouldn't be hard to come up with cases which can't.
(Think, grep MATCH out of a file, for example.)
Exactly: one of the requirements is not a regexp. Unfortunately,
procmail's rcfile syntax would make expressing the desired requirements
in a unambiguous fashion _very_ difficult. Rather that try to come up
with a sufficiently powerful syntax to describe these sorts of things,
(and then have to implement it!) I'd rather just feed the message into a
perl script. This is just too far beyond procmail's design to be
effectively and reliably added.
Philip Guenther