On Sun, 08 Feb 1998 23:12:20 GMT,
(Marek Jedlinski) wrote:
Seems to satisfy all the conditions in the recipe... and yet it passed
through my .procmailrc like a ghost. Well, serves me right for using stuff
I can't grok, since the meaning of Era's
Can you show a VERBOSE log snippet of the relevant part?
* ! ^FROM_DAEMON
* ! ^(From|To):.*(eristic)
* ^To: \/.*
* $ ^\/(From|Reply-To): $\MATCH
LOG="TRASH: from and to are the same ($MATCH)"
Also... Since everything after \/ is assigned to $MATCH, it will include
the literal "From:" string, won't it? So it has no chance to ever equal the
bare email address extracted from the "To:" header one step before. Somehow
this doesn't look quite right...
That's just for logging purposes, because I want to see whether I
matched on From or Reply-To:. MATCH will actually get set twice here.
Perhaps this is easiest to explain with an example:
Okay, the first two conditions are not relevant here, obviously.
The third condition matches on "To: foo(_at_)bar(_dot_)com" and MATCH gets set
The fourth condition, in its expanded form, will be
"^\/(From|Reply-To:): ()foo(_at_)bar\(_dot_)com" -- this is with $\MATCH
interpolated with what it got set to in the previous condition.
The backslash before the period is one of the reasons we're using $\
instead of $ (and the empty parentheses are a funny by-effect, which
is what Jari's followup was partly about).
Since this condition also contains \/, MATCH now gets set to "From:
string" which is nice to know for logging purposes, but otherwise not
BTW, I grepped the procmail manual and all the tutorials I have stashed
away for the "$\" bit and came up with nothing :)
Then you need more escape characters in your regular expression, or
you have a very old manual. (This does not work as expected in 3.10, I
believe. Obviously it's not in the 3.10 manual either, then.)
On 09 Feb 1998 10:35:45 +0200, <jari(_dot_)aalto(_at_)poboxes(_dot_)com> wrote:
9.4 What is construct $\VAR
[era and david] Procmail 3.11, $\VAR will escape regex metacharacters
in foo. It should produce a suitably backslash-escaped expression for
^^^ (this should probably be "VAR", not "foo")
You might add that it's actually really explained in the [manual] too.
Procmail's own use. In addition $\VAR will always begin with leading
You can't pass the $\VAR construct to shell programs, because there
is that leading paretheses. Here is recipe to standardize the regexp.
You can pass SAFE_REGEXP to external programs like `sed'.
This is slightly inexact; Procmail will backslash-escape according to
Procmail's needs, not sed's. For example, Procmail doesn't think
braces are magic (although that would be nice to have in Procmail as
well) whereas many modern variants of sed do.
/* era */
Paparazzi of the Net: No matter what you do to protect your privacy,
they'll hunt you down and spam you. <http://www.iki.fi/~era/spam/>