On Tue, 23 Dec 1997, Bryan Farrish wrote:
Is it OK to use a lock either inside or outside of a nest, or will this
cause problems? Ex...
:0H:
* ^To:.*me
* ^Subject:.*subscribe
{
:0B
* subscribe
NEW-SUBS
}
Procmailrc manpage states under BUGS: "A locallockfile on the recipe that
marks the start of a nested block does not work as expected." That was a
bit ambiguous sounding, so I tried a quick test using the following two
recipes:
:0:
{ TEST=TEST }
:0:$HOME/mail/INBOX$LOCKEXT
{
:0c
/dev/null
}
# The log reports is a bit weird. First recipe runs:
procmail: [22232] Tue Dec 23 13:11:01 1997
procmail: Assigning "LOGABSTRACT=on"
procmail: Assigning "COMSAT=off"
procmail: Extraneous locallockfile ignored
# I expected the line above.
procmail: Locking "pmdir.lock"
procmail: Unlocking "pmdir.lock"
# The above is weird. Procmail locked my procmail directory!
procmail: Assigning "TEST=TEST"
procmail: Extraneous locallockfile ignored
# Ok. I expected this, too.
# Now follows the second recipe. This is as I expected.
procmail: Locking "/home1/users/d/dh/mail/INBOX.lock"
procmail: [22232] Tue Dec 23 13:11:02 1997
procmail: Unlocking "/home1/users/d/dh/mail/INBOX.lock"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
Apparently _something_ might get locked, but not what one might expect,
especially if the lockfile is unspecified. The manpage is right, as usual,
if not verbose on the subject.
If you need to lock a file while an entire nested block runs, a safe way
should be to use a global lockfile, thus:
:0
{
LOCKFILE=/file/to/lock$LOCKEXT
recipes
LOCKFILE=
}
It appears to me that there are no useful functions gained from using a
locallockfile on a nested block, although something unexpected might
happen. 8-}
David Hunt