On Wed, 5 Jan 2000 15:46:08 -0800, Benjamin Elijah Griffin
<bgriffin(_at_)cddb(_dot_)com> (ur'f onnnpx, sbyxf!) wrote:
I need to have one recipe wait for a previous one to finish
before it should run. (One saves output from a filter to a
file, the next prepends that output to the message body.)
The w flag which Matt wrote about is basically the answer, but I
thought I'd throw in my old two cents (even though I think I've spent
them here before ... but I still seem to have them :-)
Merely having the recipes sequentially placed in the rc file
does not seem to be sufficent. I'd guess it is the :c flag
that causes this; does procmail still implement :c by forking?
Not only that, but basically any process will be spawned off and left
alone to finish while Procmail picks up on whatever else it was
supposed to get done, unless you put the w flag. (Obviously with f,
some sort of w is implicit, but I believe somebody recommended the w
flag with f as a rule, sometime way back when.)
So next I tried setting LOCKFILE before the first recipe and
clearing it after the second, but that does not seem to help.
No, that only prevents another copy of Procmail, or anything else
which watches the same lockfile, from doing anything (that is guarded
by this lock) until the lockfile has gone away again.
I've also tried storing the output of the filter in a procmail
variable, but it was doing something funny, removing the newlines
or somesuch.
Are you sure it's not just a case of careless (absence of) quoting?
You need to quote whitespace you want to preserve, of course, just
like in the shell.
# a procmailrc file to deal with attachments
# Benjamin Elijah Griffin 7 Dec 1999
:0
* ^Content-type:[ ]*multipart/(mixed|related)
{
# VERBOSE=yes
BASEDIR=$MAILSPOOL/attachments
# Don't let dumper and the cat below run at the same time.
LOCKFILE=$MAILSPOOL/.wait-for-it
Like I said, this merely prevents anything else from creating the
lockfile until this fellow removes it again (with LOCKFILE= ). The
proper way to serialize two sequential processes is to have them both
use the same lock, something like
:0w:same.lock
| feller one
:0w:same.lock
| feller two
This will not let "feller two" start until "feller one" has finished.
(But you will still need the w flag, unless you merely want to prevent
them from +starting+ at more or less the same time.)
# The perl script creates a directory based on the date,
# the passed in base dir, and a unique sequential number
# for each day. It returns the name of the directory.
SAVEDIR=`perl -we '# Y2K compliant script here' $BASEDIR`
So if you want this one to obey a lock, you need it to be in a recipe
(or diddle around with LOCKFILE, but) -- that's simple enough;
:0w:same.lock
SAVEDIR= | perl -we '# Y2K compliant script here' $BASEDIR
You could perhaps save a few cycles by somehow transforming the Perl
script into a Procmail one, but perhaps it's not worth the trouble.
PID=$$
# Do the dump and grab the ouput; dumper is based perl's MIME::Parser
module.
:0hbc
|$HOME/bin/dumper -o $SAVEDIR > $SAVEDIR/dumper.$PID.out
# Prepend that output to the message body (where MIME-compliant
# mail readers will ignore it).
:0bf
| (sleep 5; cat $SAVEDIR/dumper.$PID.out $MAILSPOOL/.blankline -)
LOCKFILE=
# That's it. We are done.
}
So you can get rid of the LOCKFILE business altogether (except if you
also want to prevent another copy of Procmail from entering this
critical section) and use local locks (and w flags) on the recipes
here. Actually if you use w you won't really need the lock file
anyway, but I thought it would be useful to point out the details of
the mechanics here.
Hope this helps,
/* era */
--
Too much to say to fit into this .signature anyway: <http://www.iki.fi/era/>
Fight spam in Europe: <http://www.euro.cauce.org/> * Sign the EU petition