On Tue, Mar 28, 2006 at 09:41:51PM -0500, fleet(_at_)teachout(_dot_)org wrote:
On Tue, 28 Mar 2006, Dallman Ross wrote:
I answered this part in one of my previous replies. You are
DELIVERING your message to the pipe. There is no message to
shunt to your "gotcha" recipe. The message was "eaten" by the
echo action of the previous recipe.
Ok. I think this is beginning to sink in.
Simply keep in mind that there are (a) delivering recipes, and
(b) non-delivering recipes. Putting aside for a moment the
special case of invoking the c-flag on a recipe to duplicate
a message, what distinguishes delivering from non-delivering
recipes is that the message is "consumed" by the action of
the recipe.
Examples of simple "delivering" recipes include:
:0:
/save/me/here
:0
/dev/null
:0
! forward(_at_)me(_dot_)here
:0
| shell program or command
Examples of delivering directives or assignments include:
HOST
SWITCHRC # at outermost level of some hierarchy
After each of those things, the message is no longer there.
Procmail end its run. It has done its job. It's not up
to procmail to know or decide what you mean with your
shell program or pipe command. Only you can know that.
If you intend for the pipe *not* to be a delivering
recipe, then you can:
A) Make the recipe a filter, with the f (and, essentially always,
w, together) flags. Filtering recipes return the (presumably changed)
stream to procmail for further processing.
B) Make the recipe an assignment:
:0
FOO=| shell program or command
That's nice, but there is a bug in procmail such that memory
allocation for it is destructive in unpredictable ways. Some
people have patches out there. I'd be very careful using that
without such a patch. It may work always on some systems,
never on other systems, or always the first 10,000 times and
then fail, on still other systems.
C) Use a c-flag on the recipe. Thus, the recipe itself will
still "deliver" one copy to the action-pipe, but the copy
of the message that gets created will spawn another instance
of procmail that takes over the stream from that point onward.
Therefore, to the user, the recipe nominally "acts like" it
didn't deliver. (But it really did.)
There are other things one can do as well. One is to use
this syntax:
FOO = `shell program or command`
That works just fine. It's not a "recipe," however, so I
am separating it from the recipe tutorial. In the rcfile
can go, after all, recipes, or env var assignments. And
that is all. (See 'man procmail').
Note that "FOO" can be a dummy var that you never intend to
use. That can be a neat trick.
More later -- I have to go for a bit now.
Dallman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail