Philip,
Thanks for the detailed tutorial! I'm still a little lost, though. I did
read those pages. My pea sized brain couldn't figure them out. Lock files
to my Windows cluttered mind are a novelty that I don't understand.
Here's my recipe. It pipes email to a listserve program I wrote. I need a
lock file that doesn't release until the program forks and the parent
dies. Hence the :0 w:
:0 w:
* ^TO_.*peace_talk|.*naztalk|.*healing
| /usr/local/bin/listserve.cgi
Are you saying that the following would do the trick?
:0 w: listserve.cgi.lock
* ^TO_.*peace_talk|.*naztalk|.*healing
| /usr/local/bin/listserve.cgi
If so, does it release automatically and delete itself or do I need to
write an unlink command somewhere in my listserve.cgi script?
Thanks,
Glen
On Sun, 18 Jul 1999, Philip Guenther wrote:
Glen Lee Edwards <glenlee(_at_)inebraska(_dot_)com> writes:
I'm receiving the following error message in one of my $HOME/.procmail/log
files:
procmail: Couldn't determine implicit lockfile from
"/usr/local/bin/listserve.cgi"
Any thought as to why I'm receiving this and what I need to do to correct
it?
Well, let's first check the DIAGNOSTICS section of the procmail(1)
manpage:
Couldn't determine implicit lockfile from "x"
There were no `>>' redirectors to
be found, using simply `$LOCKEXT'
as locallockfile.
If you then go back and look at the procmailrc(5) manpage it has the
following section on locallockfiles:
Local lockfile
If you put a second (trailing) ':' on the first recipe
line, then procmail will use a locallockfile (for this
recipe only). You can optionally specify the locallock-
file to use; if you don't however, procmail will use the
destination filename (or the filename following the first
'>>') and will append $LOCKEXT to it.
So, you have a recipe that calls for a locallockfile -- it has two colons
on the :0 line -- but doesn't specify the name of the locallockfile --
there's nothing after the second colon. Since it has a pipe (or filter)
action procmail looks for a ">>" in the action line so that it can use
the filename after that as the base of the name of the locallockfile.
There is none, so procmail has nothing to name the lockfile after.
Instead it locks the file "$LOCKEXT" (".lock" by default) in the current
directory. This is probably not what you want. If no lockfile is needed,
remove that second colon. If the action does need a locallockfile,
put its name after the second colon.
Philip Guenther