At 14:09 -0400 22 Sep 2001, "John P. Verel" <[EMAIL PROTECTED]> wrote:
> :0 fw:
> * ^TO_kde-linux
> | sed -e '/Subject:/s/\[kde-linux\] //g' >>  KDE-linux
> 
> While this stripped off the string just fine, I was getting funny
> results.  Specifically, my mbox N flag was getting falsely set.
> Examination of the procmail log showed why:

> What this log suggested to me was that using the f (consider the pipe a
> filter) and w (wait for the filter to finish and check its exit code)
> were not doing what I intended.  Rather than simply allowing time for
> the sed edit to operate, procmail was sending the mail to the correct
> box, but was continuing to process succeeding recipes, ultimately setting
> the flag on mbox.
> 
> I fixed this by removing the flags and the lock (:).  New recipe looks
> like this
> 
> :0
> * ^TO_kde-linux
> | sed -e '/Subject:/s/\[kde-linux\] //g' >>  KDE-linux

Just removing the f flag would have fixed it.  You should definitely
keep the lock.  I'd advise keeping the w flag as well, since it will
allow procmail to attempt to deliver the message in some other way if
the sed command fails for some reason.

Personally, I prefer to let procmail do the writing to my mailboxes.
It's likely to do a better job of recovering from errors than some
random program acting as a filter.

You could do this like:

:0fw
* ^TO_kde-linux
| sed -e '/Subject:/s/\[kde-linux\] //g'

  # Only if the above succeeded
  :0a:
  KDE-linux

In this case you want the f flag on the first recipe, but a lock is
unnecessary (it's not dealing with any files).

-- 
Aaron Schrab     [EMAIL PROTECTED]      http://www.execpc.com/~aarons/
 At the source of every error which is blamed on the computer you will
 find at least two human errors, including the error of blaming it on
 the computer.

Reply via email to