Michael Tiemann <tiemann(_at_)cygnus(_dot_)com> writes:
Given identical input, these two rules score the input differently:
procmail: Score: 8 -1 "[^a-zA-Z0-9_](job|resume|employment|referenc
es|education|qualifications|previous|visa|relocating|recommendation|position|ex
perience|design|implement|graduate|university|methodology|structured|principles
|responsible)"
procmail: Score: 0 -9 "\<(job|resume|employment|references|educatio
n|qualifications|previous|visa|relocating|recommendation|position|experience|de
sign|implement|graduate|university|methodology|structured|principles|responsibl
e)"
according to procmailrc, \< is shorthand for [^a-zA-Z0-9_], so I think
this is a bug. The input is below:
After some testing I suspect the problem you're experiancing is caused
by the following undocumented, but understandable, wart:
a leading backslash in a condition has to be doubled
A recipe that begins:
:0
* <foo
looks to procmail like a '<' size condition. That means that if you want
to match a literal '<' at the beginning of the line, you have to escape it:
# Match literal "<foo"
:0
* \<foo
So if you want the regexp to start with "\<" then you have to double the
backslash:
# Match regexp "\<foo"
:0
* \\<foo
However, less confusing alternative exists:
# Match regexp "\<foo"
:0
* (\<foo)
# Match literal "<foo"
:0
* (<foo)
Philip Guenther