Bennett Todd <[EMAIL PROTECTED]> writes:
>Note to the procmail-list folks, the mutt list grew this thread that
>spawned the question, how to deliver to Maildirs safely from an old,
>musty, non-maildir-supporting procmail. Various suggestions were
>bashed back and forth, and after I read the thread it looked to me
>like we were closing in on something actually [potentially] useful.
>Supposing a user's ISP won't upgrade their procmail, or allow them
>to install a nice tight efficient compact maildir.c executable, how
>about something like:
>
> # Needed only once, in the preamble of the procmailrc
> XXX=`date +%S`.$$.$HOST
That isn't particularly unique: %S is just the seconds of the minute.
Perhaps you meant %s, GNU's extension that gives the time_t value
(number of seconds since midnight 1970-1-1). That would be almost
certainly unique: pids are *very* unlikely to be resused within a second.
> # other recipes may come here
>
> :0
> * ^Sender: [EMAIL PROTECTED]
> {
> :0 fw
> |cat >mutt/tmp/$XXX
>
> :0 a
> |mv mutt/tmp/$XXX mutt/new/$XXX
> }
At least, you should lose the 'f' flag on the first nested recipe and
instead put the 'i' flag on the second. That's more efficient and doesn't
create problems if the mv fails for some reasons. In the above, if the
mv fails then you lose the message. Dropping the 'f' flag and adding the
'i' preserves the message past failures.
However, since you're trusting for $XXX to be unique, you might as well
go all the way and save two processes (a shell and the cat) by saving
the message directly:
:0
* conditions
{
:0
foldername/tmp/$XXX
:0 ai
|mv foldername/tmp/$XXX foldername/new/$XXX
}
If the fact that procmail might just append to an existing file (what
is it doing there anyway?), then go back to the cat, but combine the
actions:
:0 w
* conditions
|cat >foldername/tmp/$XXX && \
mv foldername/tmp/$XXX foldername/new/$XXX
The middle recipe will be faster though...
Philip Guenther
