Procmail Listerner <procmail(_at_)sunsphere(_dot_)com> writes:
...
Here's the base recipe I have now:
LOGFILE=/var/log/procmail.log
VERBOSE=on
SHELL=/bin/sh
I actually compile this assignment into procmail when I install it
locally. Cuts down on questions.
SENDMAIL=/usr/lib/sendmail
Did procmail's autoconf get this wrong? Why are you overriding instead
of fixing the compilation? (Not all invocations of procmail see the
/etc/procmailrc.)
PATH=/usr/local/bin:/usr/bin:/bin:/usr/ucb
Ditto as for SENDMAIL
...
DEFAULT=$HOME/Maildir/
DROPPRIVS=yes
:0
{
EXITCODE=69
:0 wif # recipe 1.1
*?$CONDITION
|echo "\n" \
"+------------+\n" \
"| A message. |\n" \
"+------------+\n";
:0 wr # recipe 1.2
*?$CONDITION
|
}
:0
{
EXITCODE=0
:0
$DEFAULT
}
This all looks like it should work, though I wouldn't call it the most
efficient way to write it. I would do some factoring and write the
above as:
:0
* ? $CONDITION
{
EXITCODE = 69 # EX_UNAVAILABLE
:0 wif
|echo ......
:0 wr
|
}
:0
$DEFAULT
We are observing rather strange behavior here, and suspect flushing may
be the problem. The idea is that $CONDITION is some external program which
tests something, and returns 0 upon success, 1 otherwise (we've been using
true and false for testing).
Assume that recipe 1.1 returns true: we should see "A message" come out via
STDOUT. This only happens if:
a) recipe 1.2 is present
b) recipe 1.2 is is true as well.
Correct
If recipe 1.1 is false but 1.2 is true, we see the message (as expected).
Correct
In order for recipe 2.1 to happen, both 1.1 and 1.2 must be false, or 1.2
must be missing.
Nope. 2.1 will happen if 1.2 fails or is missing. 1.1 is a filtering
recipe and therefore never terminates procmail. Procmail doesn't exist
just because it hit a close brace. The only reasons for procmail to
stop processing an rcfile before its end are:
1) it processed a successful delivering recipe with the 'c' flag, or
2) an assignment to HOST occurred which didn't match, or
3) an assignment to INCLUDERC occurred and procmail stopped processing it
before its end for one of these reasons.
What makes no sense is that if recipe 1.2 is not present (we really don't
need it), recipe 1.1 does not even happen:
Yes it does. See below.
...
root(_at_)blah:~# procmail -d foobar < /tmp/message
root(_at_)blah:~# echo $?
0
Procmail entered the braces, performed the assignment to EXITCODE (69),
did the filtering recipe, exited the braces (but kept processing),
entered the next braces, performed the assignment to EXITCODE (0),
did the deliver to $DEFAULT, then exited with $EXITCODE = 0.
* log:
...
procmail: Assigning "DROPPRIVS=yes"
procmail: Assuming identity of the recipient, VERBOSE=off
Hmm, perhaps this would all be clearer if you put a VERBOSE=on
right after the DROPPRIVS=yes.
Folder: /home/foobar/Maildir//tmp/920958381.25113.blah 50
Here's the final proof: that 50 at the end of the line. That's how big
the message that procmail delivered was. The "echo" data from the
filter is exactly 50 bytes. Did you actually _check_ that message in
the Maildir to see what it contained?
Philip Guenther