I wrote:
>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.
...
>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
> }
I just realized that the first of the nested recipes should have the 'r'
flag, as maildir format doesn't need embedded "From " lines to be escaped.
Also, placing the 'r' flag on the second of the nested recipes will
marginally speed things by saving procmail a tiny bit of work.
:0
* conditions
{
:0 r
foldername/tmp/$XXX
:0 air
|mv foldername/tmp/$XXX foldername/new/$XXX
}
Philip Guenther
