On Mon, 2 Jun 1997 07:40:00 -0700 (PDT),
Dave/WebMaster <ddave(_at_)ddave(_dot_)com> wrote:
On Mon, 2 Jun 1997, era eriksson wrote:
You should of course use the same lock file when accessing these files
elsewhere in your .procmailrc.
Is the lock file going to be necessary for reading or just writing to the
files?
The purpose of a lock is to make sure two processes don't run into
each others' feet. You use a lock where you do not want two processes
to do "something" at the same time. If reading a file is a "something"
you want to prevent, use a lock file on a recipe which does try to
read a file.
Mostly, Procmail lock files are just used to prevent two instances
of Procmail from attempting to write to the same file at the same time
(because this will likely mess up the file with intertwined partial
writes from the two processes). But the concept is more general than
that.
For instance, you can have one recipe which manipulates a data file,
and another recipe which uses that data file. Since the data file will
presumably be in an inconsistent state while the manipulator
manipulates it, you don't want the user recipe to use that file during
that time. Solution: Use the same lock file on both recipes.
To return to your question; in this case, you should probably not
allow reading from the data file while it's being manipulated, and
vice versa.
I don't have your original recipes on file here, but here's a
template you can hopefully put to good use:
# Only allow one instance of Procmail to be executing this
# section of the rc file at any given time
LOCKFILE=fgreplock
:0
* Subject:[ ]*(join|subscribe)[ ]*list\>
| ... add person to list
:0
* conditions for a message to be distributed to the list
! `cat subscribers-file`
# End of critical section
LOCKFILE=
The matching on the subject line looks a bit sloppy to me; are you
sure you want the wildcard there?
* ^Subject: (join|subscribe) list(\>|)
What is your opinion of this expression?
You might want to loosen up the whitespace (i.e. permit an arbitrary
number of spaces and tabs).
The expression (\>|) looks like it used to be (\>.*|)$ but got
"improved" somewhere along the way ... (\>.*)?$ might be more readable
if you want that.
Hope this helps,
/* era */
--
Defin-i-t-e-ly. Sep-a-r-a-te. Gram-m-a-r. <http://www.iki.fi/~era/>
* Enjoy receiving spam? Register at <http://www.iki.fi/~era/spam.html>