Stan Ryckman wrote,
| I was wondering if the following advice in the man page "procmailex"
| might be buggy?:
|
| If you are fairly new to procmail and plan to experiment a
| little bit it often helps to have a safety net of some sort.
| Inserting the following two recipes above all other recipes
| will make sure that of all arriving mail always the last 32
| messages will be preserved. In order for it to work as
| intended, you have to create a directory named `backup' in
| $MAILDIR prior to inserting these two recipes.
No. But maybe you didn't notice the last sentence. You have to create a
subdirectory named "backup" in $MAILDIR before using the recipes. If you did
create that directory, then the recipes should work.
| :0 c
| backup
|
| :0 ic
| | cd backup && rm -f dummy `ls -t msg.* | sed -e 1,32d`
| I ask, because I have these lines at the top of my .procmailrc,
| and I logged a message about rm not finding files when I sent
| a message, Cc: to myself, and Return-Receipt-To: myself; thus
| three messages (the Cc and two receipts) slammed into my mail
| all at about the same time.
Your rm is broken if it said anything about nonexistent files when you were
using the -f option. Perhaps the error message was from ls, saying that it
couldn't find the files?
| Shouldn't both of these recipes have a lock?
No, because the first saves to a directory; procmail will find a unique
filename on its own. If you didn't previously create a subdirectory of
$MAILDIR named backup, then procmail would try to save to a folder named
$MAILDIR/backup, and then you'd need a local lockfile. (But then the
second recipe will fail, as it tries to "cd backup".)
The second recipe doesn't need a local lockfile because it doesn't write
any text out. Lockfiles are for keeping or more processes from altering
the same file at the same time. Two rm processes at the same time shouldn't
be a problem, because the -f option is supposed to suppress error messages
in the case where both ls's run before either rm.
David W. Tamkin dattier(_at_)wwa(_dot_)com 2094393(_at_)mcimail(_dot_)com