On Sat, 18 Jan 2003, Professional Software Engineering wrote:
At 20:05 2003-01-18 -0500, fleet(_at_)teachout(_dot_)org did say:
* From:[ ].*\/\(_at_)(_dot_)*[^\>]
gets me the domains properly as @whatever
* Message-Id:[ ].*\/\(_at_)(_dot_)*[^\>]
gets me the domains properly as @whatever
[^\>] is a curious expression in your messageid extraction. Do you
actually know what it does? '\>' is itself a character class expression.
He may have meant "any character that is not a word delimiter", the way
you can say [^\w] in Perl (which means the same as \W) -- and that seems
to be what you think it means as well? Procmail regexs don't work that
way; '\>' is only a special character class when it appears outside [].
Inside [], it's the class consisting of backslash and greater-than.
However, I think it's more likely he meant [^>], but I don't think he
wants .*[^>] -- that'll consume the entire line after the @ if the address
happens not to be enclosed in < >.
:0
* From:[ ].*\/\(_at_)(_dot_)*[^\>]
* $MATCH ?? Message-Id:[ ].*\/\(_at_)(_dot_)*[^\>]
foundit
I'm surprised it supposedly works for ANY of them - you're checking $MATCH
I'm really not sure WHAT he's checking there. The syntax for checking
the value of $MATCH against another expression would normally be
* MATCH ?? Message-Id:[ ].*\/\(_at_)(_dot_)*[^\>]
So I'm not sure whether procmail parses his expression as
* $ MATCH ?? Message-Id:[ ].*\/\(_at_)(_dot_)*[^\>]
or whether it's trying to find a variable whose _name_ is literally
dollar-em-ay-tee-cee-aitch and compare the value of that (impossible)
variable to the pattern.
Is there some reason you believe that the DOMAIN from From: will contain
"Message-Id:" for instance? Do you not see the glaring problem?
On Sun, 19 Jan 2003 fleet(_at_)teachout(_dot_)org wrote:
What I saw was:
MATCH {which contained} @some.dom
* From:[ ].*\/\(_at_)(_dot_)*[^\>] {resulted in }
AND
* Message-ID:[ ].*\/\(_at_)(_dot_)*[^\>] {resulted in }
MATCH {which contained} @some.dom
SO
if A + B = C and D + E = C then C = D + E or something
and all I needed was the proper incantation.
So what gave you the idea that '??' means 'AND'?
The proper incantation to 'AND' two conditions together is simply to put
them together:
:0:
* ^From:[ ].*\/\(_at_)[^> ,]*
* ^Message-ID:[ ].*\/\(_at_)[^>]*
foundit
The use of \/ to extract into MATCH is extraneous there. Is there some
reason you want to know what the domains are? Perhaps you're trying to
find out whether the Message-Id contains the same domain as the From?
That would be something like this:
:0:
* ^From:[ ](_dot_)*\(_at_)\/[^> ,]*
* $ ^Message-ID:[ ](_dot_)*\(_at_)[^@]*$\MATCH>
Where $\MATCH means the value of MATCH as a quoted regex, so that e.g.
the '.' character matches only a literal '.' rather than any character,
and the leading $ means to expand variables like $\MATCH within the
rest of the condition line.
Extract each value in separate recipes, then compare them in a third.
I also considered this, but I haven't yet found an example of assigning
MATCH to a variable. I suppose it's something difficult like
VAR1 = $MATCH ?
Yes. But not in a condition line. Like so, usually:
:0
* ^From:[ ](_dot_)*\(_at_)\/[^> ,]*
{ DOMAIN = "$MATCH" }
:0:
* $ ^Message-ID:[ ](_dot_)*\(_at_)[^@]*$\DOMAIN>
foundit
Do I need to also invoke the "This $ makes everything
work like a shell expression" thingy?
That isn't what the thingy means, but no.
This would also eliminate the problem of dealing with a situation where
Message-Id appeared before From: I suppose
There is no such problem. Each condition line line (the ones that begin
with '*') starts the search over at the beginning of the header, so it
doesn't matter whether the order of the header fields matches the order of
the conditions. In fact, you have to do a lot of extra work to make it
matter, if that's important for some reason.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail