Jesper Pedersen wrote,
| When I turn on extended diagnostic (VERBOSE = yes) the logfiles get
| cluttered up by the different subprocesses:
|
| :0c {
| ...
| }
| This will (as I see it) start a new subprocess for the commands within {}
| while the original procmail process will continue.
Does it work if the left brace is on the same line as the opening colon?
Anyhow, back to Jesper:
| This makes it very hard to see what comes from which procmail line.
| Is there a way to "liniarize" this, so the original procmail command will
| not continue until the subprosses has stoped? Or to add line numbers in
| the from the recipe file.
First, are you sure you need a clone? Maybe the code inside the braces can
be run in the parent process, and then there will be no problem.
Second, many of the lines logged are preceded with a process ID, so that
should tell you which procmail process logged them. The younger PID must
belong to the child.
One way that will definitely work is to name another logfile inside the
braces, and then the child procmail will do its logging somewhere else:
:0c
* conditions if any
{
LOGFILE=some_other_file
...code...
}
Even if the clone falls through the right brace and reads later recipes (as
maybe you want it to do), it will continue logging to its own logfile.
Now, this may be worth a try, though I'm not sure if it will work (it
certainly will not if there is no `c' flag to spawn a clone):
:0cw
* conditions if any
{
...code...
}
| Is there anotherway than the following to junk mail:
|
| :0
| /dev/null
That's the basic idea, though there are ways to improve it; I'll get to those
below, but first:
| or
| :0
| {}
That second way will save mail to a folder named $MAILDIR/{}, so it won't
do the job. If you meant this:
:0
* conditions if any
{ } # note the space between the braces
... then that is a no-op; procmail will go on reading recipes right past it.
If you know that the current rcfile will always be read by a procmail process
that has no additional rcfiles named on its command line, this is the fastest
way to drop unwanted mail into the bit bucket:
:0
* conditions if any
{ HOST }
Unsetting HOST (or trying to assign a value to it that differs from its
current value somewhere in the first nine characters) makes procmail jump
to the next rcfile on its command line; if there are no more rcfiles re-
maining to jump to, it loses the incoming message and exits.
If you are not positive of that, the next best way is to save the message
to /dev/null as you illustrated. One thing that can usually help is the `h'
flag: that way procmail writes the head to /dev/null and just loses the body.
If the mail you are dumping normally has short bodies, though, the `b' flag
is better, because then procmail will save the body to /dev/null and lose the
head; but `h' or `b' (one or the other, not both) always helps.