At 14:08 2001-11-29 -0600, David W. Tamkin did say:
| While it applies to the trailing newline, it DOES NOT with the leading
| anchor, since there is no _newline_ present at that end of the string
| (you're welcome to make a test script to demonstrate this to
| yourself).
Huh?
Newline is among the characters that \< will match. Newline is also among
the characters that \> will match. [In fact, \< and \> really mean exactly
the same thing in procmail regexps.] Writing (\<|^) is redundant, like
writing ([a-z]|j).
I realize the macros represent identical regexps - but the passed string is
not identical at the BOL and EOL! The way you describe it, the string is
stored as (quotes used to emphasize where newlines would appear within the
string buffer):
"
someaddr(_at_)domain(_dot_)tld
"
I contend they're stored as:
"someaddr(_at_)domain(_dot_)tld
"
What you may be seeing as matches from formail-extracted addresses is as
the result of the leading space:
" someaddr(_at_)domain(_dot_)tld
"
(which the leading word break would match)
To demonstrate to yourself, I invite you to run the following example script:
SOMEADDR=joeuser(_at_)domain(_dot_)tld
# (realize that the object of this rule is to allow for addresses in a
# variety of formats, not JUST the one above -- but the one above is the
# case where the LEADING wordbreak will fail)
:0:
* SOMEADDR ?? \<joeuser(_at_)domain\(_dot_)tld\>
test.true
Which (on 3.15 - perhaps you're seeing something different if you're
running 3.2x) results in:
procmail: Assigning "SOMEADDR=joeuser(_at_)domain(_dot_)tld"
procmail: No match on "\<joeuser(_at_)domain\(_dot_)tld\>"
If instead, that regexp is changed to include the leading anchor as I suggest:
* SOMEADDR ?? (^|\<)joeuser(_at_)domain\(_dot_)tld\>
we get:
procmail: Assigning "SOMEADDR=joeuser(_at_)domain(_dot_)tld"
procmail: Match on "(^|\<)joeuser(_at_)domain\(_dot_)tld\>"
I am eager to hear the explanation for what can only be explained as an
anomaly -- mind you, I see it operating _EXACTLY_ as I expect it to, but
the results of this test don't jive with what you're saying.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail