era eriksson <era(_at_)iki(_dot_)fi> writes:
On 6 Jan 2000 18:56:11 -0000, John Conover <conover(_at_)inow(_dot_)com> wrote:
I have a shell script, myscript, that I want to execute that makes
some temp files when it runs, so I need to post a lock file:
:0 h :myscript.lock
* ^some_key_word:
{
myscript >> xyz
This is a syntax error. You mean
:0h:myscript.lock
* condition
{
:0
| myscript >>xyz
## etc
}
True, but this does not address the "extraneous locallockfile ignored"
message. If you just need the lockfile to last while the script is
executing, put the locallockfile on the recipe that actually invokes
the script:
:0
* condition
{
:0 h: myscript.lock
| myscript >>xyz
#other recipe(s) here
}
Note carefully that the 'h' flag goes on the recipe that actually dumps
the message somewhere. The 'h', 'b', 'r', and 'i' flags do nothing on
the recipe that starts a nested block (newer versions of procmail will
emit warning messages about this).
Also note that if a nested block contains just a single recipe and
no variable assignments, then the outer and inner recipes *usually*
be combined into one (it doesn't always work with weighted recipes and
some uses of the 'A' and 'E' flags).
If you need the lockfile to be in place across multiple recipes then
you can use a regional lockfile via the LOCKFILE variable:
:0
* condition
{
LOCKFILE = myscript.lock
:0
| myscript >>xyz
#other recipe(s) here
# clear the lockfile
LOCKFILE
}
Okay, so when do locallockfiles actually work on nested block recipes?
They work if and only if the nested block is a 'cloning' block, where the
recipe has the 'c' flag such that procmail forks to process the block.
The parent process can then handle the lockfile while the child process
is in the block. However, unless you already need the cloning behavior,
it's generally faster to the use explicit lockfile created via LOCKFILE.
Philip Guenther