`Philip Guenther' wrote
The problem is that the assignment to RESULT occurs in a subprocesses (the
shell processing that action) and procmail therefore never sees it. In
this case some rearranging can take advantage of another procmail action
format to solve your problem:
:0i:result.lock
RESULT=| (echo "From: $FROM"; echo "To: $TO"; echo "Cc: $CC"; \
echo "Found: $FOUND" ) > headers.tmp; \
myfilter headers.tmp | tee -a result.list1
The "variable=|" action format tells procmail to grab the output of the
action and store it in the variable given. The "tee -a" command replaces
the "echo $RESULT" that previously was there; RESULT is no longer set
inside the processing of the action, so we have to sneak a copy of the
output of 'myfilter' directly.
Also, if myfilter can take its input on stdin instead of having to store
it in a file and name it on the command line, or if it can be changed to
do so, then the action gets even simpler:
:0i:result.lock
RESULT=| (echo "From: $FROM"; echo "To: $TO"; \
echo "Cc: $CC"; echo "Found: $FOUND" \
) | myfilter headers.tmp | tee -a result.list1
No temporary files!
>What am I doing wrong ? Besides, are there other stupid/dangerous
>things in what I wrote above ?
You need the 'i' flag on both of those recipes, as neither action reads
the message being piped to it by procmail, and procmail will consider
that an error without the 'i' flag. Also, with as complicated an
action as the one you had, I would want to explicitly name the lockfile
just so I didn't wonder which ">>" procmail looked at.
Thanks. Actually, I solved my problem a long time ago...
Denis