[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mutt-users
Subject:    Re: ad hoc mail filtering?
From:       David Champion <dgc () uchicago ! edu>
Date:       2003-09-26 23:13:09
[Download RAW message or body]

* On 2003.09.26, in <20030926212839.GA18432@thor.cs.utexas.edu>,
*	"christopher j bottaro" <cjb@cs.utexas.edu> wrote:
> awesome, thanks.  ok, almost there.  one last thing...
>
> so now i have a key bound to "!formail -s procmail < $HOME/mailbox",
> now how do i get rid of the messages in $HOME/mailbox? can i simply
> execute this command instead: "!formail -s procmail < $HOME/mailbox &&
> rm $HOME/mailbox"? this seems scary to me. what if while that command
> is executing and the mail system is simultaneously delivering mail?
> won't i end up loosing messages? for example, what if "formail -s
> procmail < $HOME/mailbox" finishes running, the mail system delivers
> more mail to $HOME/mailbox, THEN the "rm $HOME/mailbox" command runs.
> i'll lose those newly delivered messages, no?

Yes, that's a problem. it's probably best treated with a small shell
script to handle the locking and procmailing; you can call this
externally, or from inside your mutt macro.

Without knowing the locking semantics of your mail delivery system, I'd
have to suggest renaming the mailbox to something else before extracting
from it:

--- snip ---
#!/bin/sh
DROPBOX=$HOME/mailbox
TEMP=$DROPBOX.tmp

mv ${DROPBOX} ${TEMP} &&
lockfile ${TEMP}.lock &&
formail -s procmail <${TEMP} &&
rm -f ${TEMP}.lock ${TEMP} ||
{ echo "error"; exit 5; }
--- snip---


But if your mail delivery system respects conventional ".lock" files,
then you're better off without such complexity:

--- snip ---
#!/bin/sh
DROPBOX=$HOME/mailbox
TEMP=$DROPBOX				# this line changed

#mv ${DROPBOX} ${TEMP} &&		# this line changed
lockfile ${TEMP}.lock &&
formail -s procmail <${TEMP} &&
rm -f ${TEMP}.lock ${TEMP} ||
{ echo "error"; exit 5; }
--- snip---


It's almost the same, but it locks the actual dropbox and doesn't
rename.

There are tomes written on best practices for locking, and this probably
doesn't meet all the criteria. But it's hard to address without knowing
particulars of your environment. This is probably good enough. :)

-- 
 -D.    dgc@uchicago.edu
 University of Chicago > NSIT > VDN > ENSS > ENSA > You are here
 .  .  .  .  .  .  .
 always line up dots
[prev in list] [next in list] [prev in thread] [next in thread]