I'm puzzled by the following... is it that $MATCH contains
newlines? I've simplified the more interesting case to this
(where the simplified filter just echoes the body back).
The rc file:
=====begin file 1.rc =====
SHELL=/bin/sh
MAILDIR=$HOME/playrc
LOGFILE=$MAILDIR/log_p_rc.test
LOGABSTRACT=all
COMSAT=no
VERBOSE=YES
:0
* ^Subject:.*magic
{ }
:0abBfw
* ^^\/(.*($))+
| echo "$MATCH"
:0e:
filter_error
:0:
ready_for_more
=====end file 1.rc =====
The command I repeatedly used is:
procmail -m 1.rc < testmail
where file "testmail" is:
=====begin file testmail =====
From somelist(_at_)somewhere(_dot_)com Tue Aug 29 22:01:42 2000
Subject: A small test case - magic
small test case
=====end file testmail =====
The behavior is that MOST of the time the message goes to file
"ready_for_more" but a substantial amount of the time it goes
to "filter_error". When it does, the log isn't terribly informative;
the relevant excerpt:
=====begin log excerpt=====
procmail: Match on "^Subject:.*magic"
procmail: Assigning "MATCH="
procmail: Matched "small test case
"
procmail: Match on "^^\/(.*($))+"
procmail: Executing "echo,small test case
"
procmail: Error while writing to "echo"
procmail: Rescue of unfiltered data succeeded
procmail: Locking "filter_error.lock"
procmail: Assigning "LASTFOLDER=filter_error"
procmail: Opening "filter_error"
procmail: Acquiring kernel-lock
procmail: Unlocking "filter_error.lock"
=====end log excerpt=====
Adding the "i" flag results in no error message, and the whole body
goes to the "ready_for_more" file with nothing lost, all the time.
(Plus one extra newline, but that's a minor issue for another time.)
So what can the occasional error be, such that when "i" is used to
ignore it, no bytes get lost anyway (which contra-indicates the error
being an early closed pipe)?
Sorry if I'm overlooking something obvious here!
Thanks,
Stan
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail