Luke Davis <ldavis(_at_)voicenet(_dot_)com> writes:
example 1:
:0w :message.lock
* some test(s)
{
:0c
message
:0
| process-message
}
Question 1:
Will the above script leave the lock file in place, untill after the
process-message program exits?
To quote the procmailrc(5) manpage:
BUGS
...
A locallockfile on the recipe that marks the start of a
non-forking nested block does not work as expected.
So the answer is "no". One reason is that it would allow you to
specify an unlimited number of simultaneous lockfiles, and procmail has
no way to keep track of all of them. A cloning/copying nested block
(one with the 'c' flag) can let you get away with this by having the
_parent_ process keep track of the lockfile. However, you then have to
deal with killing off the child at the end of the block if it doesn't
manage to deliver. I therefore find this to be more work than the
solution presented below.
Before giving that solution, I'll ask why process-message can't just
use the copy of the message fed it on stdin. Does it need to read
through it twice, or something? Anyway, if it isn't reading its stdin,
then you should put the 'i' flag on that (sub-)recipe.
The solution I and others prefer and recommend for this case is to use
a global lockfile:
:0
* some test(s)
{
# Obtain the lock
LOCKFILE = message.lock
:0c
message
:0w
|process-message
# Release the lock
LOCKFILE
}
Will the program be able to write to the message file.
Why shouldn't it be able to?
Example 2:
:0 :test.lock
{
some scripts
}
Question 2:
Will the lock file "test.lock" be inplace for the duration of the above
set of scripts?
Will the scripts within be able to write to the test file?
This is exactly the same as the previous question, with the same answer.
Philip Guenther