"J.Sigbrandt" <jay(_at_)elec(_dot_)gla(_dot_)ac(_dot_)uk> writes:
I am subscribed to a high volume mailing list that sends
me between 50 and 150 messages a day.
This puts a big load on me and also my system, so I have
subscribed to the digest version of the list.
My current procmail rule looks like this:
# Filtering for the HVML Digests
:0: HVMLIn/.lock
* ^From:(_dot_)*HVML(_at_)somewhere(_dot_)net
| formail +1 -I "Reply-to: HVML(_at_)somewhere(_dot_)net" \
-ds /usr/lib/mh/rcvstore +HVMLIn
(note that formail splits the digest and rcvstore puts the
messages into MH style folders and updates the unseen
sequences.)
What I am looking for, is a method to do the above but
WITHOUT updating the unseen sequences ... i.e. I want formail
to simply add the individual messages straight into the
IxionIn folder with no further fuss.
How about if you saved the digest message in the folder without
splitting it, then call the MH 'burst' program on it there. This would
require only one process.
:0
* ^From:(_dot_)*HVML(_at_)somewhere(_dot_)net
{
# You may want to set LOGABSTRACT to "no", either here, or
# after the recipe that delivers to the folder, depending
# on what sort of logging information you want to see.
# Keep another procmail process from delivering and bursting
# at the same time as this one.
LOCKFILE = $HOME/Mail/HVMLIn.lock
# deliver the message to the MH folder
:0 c
$HOME/Mail/HVMLIn/.
# Extract the message number that procmail used
:0
* LASTFOLDER ?? ()\/[0-9]+$
{ }
# Brust the message. I like to call burst with the "-inplace"
# flag, but you'll want to try it out by hand, as if the digest
# has info after the last message delimeter, it'll be lost.
# You could work around that by prefacing this all with a body
# filter that added another delimiter to the bottom of the
# message, but that's gross and should be avoided if not needed.
:0 wi
|burst -inplace -quiet +HVMLIn $MATCH
# The global lockfile will automatically be removed when
# procmaile exits.
}
Now, before you actually use this, there's a problem with it: burst
wasn't meant to be run in the background (like the rcv* programs), so
it'll change your current folder, and current message within the HVMLIn
folder. This may confuse exmh. If you MH was built with the OVERHEAD
option, then there's a solution, albeit a gross one: by setting the
environment variable MHFD to the number of a file descriptor which is
open for reading from an alternate mh_profile (say, .mh_profile.burst)
which has a "context:" entry specifying a different context file then
your normal one, you can make get burst to leave your normal context
file alone. By including a "mh-sequences:" entry in this alternate
mh_profile, you can similarly avoid problems with the current message
number changing. Assuming you named the alternate profile,
"$HOME/.mh_profile.burst", that last sub-recipe above would be changed
to read:
MHFD = 7 # 7 is fairly safe as far as file descriptors go
:0 wi
|burst -inplace -quiet +HVMLIn $MATCH 7<$HOME/.mh_profile.burst
Yes, that's gross. Yes, every MH program should be rewritten to have
"-profile <profilename>" and "-context <contextname>" switches. Don't
hold your breath.
The advantages of the ideal solution would be:
- I won't get distracted with exmh telling me there are 100 new
messages for me and be tempted to read them all in one go ;-)
- formail won't be calling rcvstore 150 times every day!
I don't know if this meets the first of your criteria, but it certainly
meets the second.
Philip Guenther