Ralph SOBEK <sobek(_at_)irit(_dot_)fr> writes:
...
Yes! For example:
:0
* 9876543210^0 $ ^(From|Subject):.*\/\<(${regexp})s?\>.*$
* 9876543210^0 B ?? $ ()^\/.*($.*)?\<(${regexp})s?\>.*($.*)?
{
LINES = $MATCH
}
:0 A
*$ MATCH ?? ()\/$regexp
{
NAME = $MATCH
LOG = "--> Name = $NAME <--$NL"
}
# Baier is one of the patterns in $regexp
:0 a:
* NAME ?? Baier
* ! LINES ?? Research: SOBEK, BAIER/BEIER
$outfile
In this case, I would like to continue the initial match from the tail
of the first find. Maybe all that would be necessary would be a
Ignoring the possiblity of the initial match being against the header,
if you want to search the part of the body after the text matched by
LINES, just use $\LINES as an anchor:
:0 B
* $$\LINES.*\/whatever...
Handling the possibility of the first match being against the header can
be done by turning the initial recipe into two and setting a flag
variable. Hmm, let's see:
# Unset 'found'
found
:0
* $ ()\/^(From|Subject):.*\<(${regexp})s?\>.*$
{
found=H
LINES=$MATCH
}
:0 EB
* $ ()\/^.*($.*)?\<(${regexp})s?\>.*($.*)?
{
found=B
LINES = $MATCH
}
:0
* !$${found+!}
* MATCH ?? $ ()\/$regexp
{
NAME = $MATCH
LOG = "--> Name = $NAME <--$NL"
}
:0 A$found :
* NAME ?? Baier
--> * $$\LINES.*\/whatever here...
$outfile
The indicated line, combined with the expansion of 'found' in the recipe
flags should anchor you _fairly_ well. However, if there are two blobs
of text that could have been matched by the first regexps, one of which
is followed by okay stuff and the other not, then this may or may not do
what you want. Or that may be unlikely enough that you don't care.
"goto" operator or "next match" operator, that would continue the
process where the last was left off. May this be possible?
Like the magic \G anchor in perl. (Hmm, I wonder if people are
beginning to suspect that I think perl's regexps are really cool... Of
course, they're so hairy you need a lawnmower to figure out what one
actually does!)
PG> Perl's mongo regexps can do this with the new, experimental, and scary
PG> "(?{ code })" syntax, but lacking a good base language, this is quite a
PG> bit beyond the capabilities and desgin of procmail.
Maybe I would need such a `mongo' regexp compiler!
The trick is figuring how to express what you want, assuming you even
know what _that_ is!
Philip Guenther