On Sun, 21 Jan 2001, Holger Wahlen wrote:
I've dabbled a bit in more complex [recipes], but not too deeply. I
usually just ask for help to ensure no mail is lost.
Recently I dabbled too deep, and did lose a bunch. ;o)
You could have something like
:0 c:
backup
at the beginning of your .procmailrc to save a copy of every incoming
message to a backup folder while you're testing something new, that
would ensure you don't lose anything for good even if there's
something wrong with your recipes.
Yes, I've got the backup recipe in my .procmailrc, however it
only backs up like 32 messages. I am on about 80+ mailing lists
and mail downloads almost constantly. This means that it backs
up about 2 minutes worth of email messages. Not very useful
really. No idea how to make it back up a useful amount of
messages - 1000+ or so.
Most likely, a better alternative would be a mail backup that
puts a copy of all messages received for the entire DAY into a
file in a backup directory with the date as part of the title.
Something like:
~/mail/incoming/backups/backup-$(date +"%Y-%m-%d")
And then have it auto-delete all backup files that are a month
old. This would likely be most easily implemented as a cronjob.
:0c:
backups/backup-$(date +"%Y-%m-%d")
Will the above command substitution work?
Subject: [Xpert]Memory Leak in XmuClientWindow() ?
My rule for this list goes something like:
:0:
* ^X-BeenThere:(_dot_)*xpert(_at_)XFree86(_dot_)Org
XPERT-XFREE
Um, I guess you just forgot to include the X-BeenThere header in the
example snippet?
Yes, I didn't turn full headers on.. It is there though.
And if it's there, you probably can count on it to have a fixed
number of spaces/tabs after the colon, so you should be able to
use that instead of ".*".
I'm not too worried about other lists matching this as it is
extremely unlikely. The "." could be changed to "\." though, but
again, unlikely to ever matter....
I want to integrate the recipe you provide above into this rule,
so that the filter is only applied to this specific list.
Would the following be correct?
:0
* ^X-BeenThere:(_dot_)*xpert(_at_)XFree86(_dot_)Org
{
:0hf
* ^Subject:.*\[Xpert\]
| sed 's/\[Xpert\] //'
:0:
XPERT-XFREE
}
That's fine - just a few details: (1) Do you really need to check the
subject line after you've already identified the message as coming
from the list? Don't all list messages have the "[Xpert]" added
anyway?
Yes. If the list ever disables the [Xpert] thing, I don't want
sed getting called. Actually, looking at the above, sed would
change all occurrences of [Xpert] in the entire header the way it
is there no?
Should change to:
sed -e 's/^Subject:(.*)\[Xpert\](.*)/Subject: \1\2/'
Which is perlish syntax.. Does sed support it? I don't want to
use perl as it is a hog for this...
(2) Your sed script removes "[Xpert] ", with a trailing space,
from the subject line; the lists I know all do have such a space after
the bracket, but it doesn't appear in your example header, so nothing
would happen there.
Correct. The space was accidental.. ;o) Removed.
(3) There's no need to put a "\" before the "]" (though it
doesn't do any harm either), neither in procmail's condition
nor in the sed script; only the "[" has to be escaped.
I use regex's with perl/sed/awk/grep and none of them seem to
work the same. When I leave out \'s with grep things break.. I
put them in most of the time "just in case". Bad regex's in mail
filters can be devastating... ;o)
I just tested sed on the commandline and if you do not put \[, it
will treat [ as a regex metacharacter.
(4) You might consider adding a "w" flag to the first recipe in
the braces (:0 hfw). This way you have some kind of safety net:
if sed fails, e.g., because of a typo causing a syntax error in
the script, procmail will continue to process the original
message instead of sed's empty output, so you don't lose
anything. In this case here the danger is probably neglectible,
but as soon as you start to have more complicated filters, this
can become useful pretty soon.
Hmm. Sounds good. So here is my current incarnation:
:0
* ^X-BeenThere:(_dot_)*xpert(_at_)XFree86\(_dot_)Org
{
:0 hfw
* ^Subject:.*\[Xpert\]
| sed -e 's/\(^Subject:.*\)\[Xpert\]\(.*\)/\1\2/g'
:0:
XPERT-XFREE
}
Can anyone see any problems with the above now? If there is a
way of avoiding the fork/exec of sed using procmail magic, I'd
like to try if it speeds the thing up, but it isn't extremely
critical to me.
Looking it over, I forsee 2 things now. The "* ^Subject..." line
does now seem redundant since sed is only getting the header, and
there should only be on "Subject" line in the header. The /g on
sed would catch 2 even if it were legal anyways.
The other thing is, what if more than one [Xpert] appears in the
subject? I'd like to silence all of them. So would the
/g take care of that, or would I have to resort to more trickery?
Is the last part necessary, or can I take out the :0: and move
XPERT-XFREE up? Combining these two things would give:
:0
* ^X-BeenThere:(_dot_)*xpert(_at_)XFree86\(_dot_)Org
{
:0 hfw
| sed -e 's/\(^Subject:.*\)\[Xpert\]\(.*\)/\1\2/g'
XPERT-XFREE
}
Or am I sniffing glue? Would this then allow me to do:
:0 hfw
* ^X-BeenThere:(_dot_)*xpert(_at_)XFree86\(_dot_)Org
| sed -e 's/\(^Subject:.*\)\[Xpert\]\(.*\)/\1\2/g'
XPERT-XFREE
Please let me know any errors in any of the above examples.
Thanks for all the suggestions everyone! Keep up the great work!
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
"Facts do not cease to exist because they are ignored."
- Aldous Huxley
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail