Aaron, Interesting. Your use of the "only if the above succeeded" is something I'd not thought of. If would fix a glitch I saw in the procmail log, which is this goofy looking entry: procmail: Assigning "LASTFOLDER= sed -e '/Subject:/s/\[kde-linux\] //g' >> KDE-linux" Presumably, the added recipe will cause LASTFOLDER to be set simply to KDE-linux, the desired outcome, otherwise to mbox, an okay fallback. I'll give this a go in the morning. Bit too late for tinkering with dot files, especially after some free beers :) Thanks for your note. On 09/22/01, 08:02:20PM -0500, Aaron Schrab wrote: > 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. -- John P. Verel Norwalk, Connecticut
