At 11:12 2010-06-07 +0200, Hylton Conacher (ZR1HPC) wrote:
I receive a LARGE number of emails(Approx 1500 per month)
LARGE appears to be a relative value.
that are sorted into their different folders and the really important ones
stay in my Inbox to be looked at first.
You can always _deliver_ them into your inbox. Delivery (without lingering
copies) will also cease the processing of the procmailrc:
:0:
$DEFAULT
I would therefore like to having a working procmailrc file that I can
periodically add to. It is very possible that I remember part of a
future recipe but nothing more. I would therefore add the details I can
remember into the procmail file as part of a future recipe and know that
Procmail will not process the text I have jotted down because there was
and EOF before it.
It is inadviseable to use your live mailstream as a testbox. You should
put these into a separate file and develop them there.
Would you compose an official report and have random jumbles of thoughts
and figures appended below your signature line?
As Olivier stated earlier I could just comment them out but procmail
will still read the file to the end. Apart from this there are currently
over 5 A4 pages of recipes that need completing when the relevant email
arrives i.e. 5 pg to be commented out, line by line!
Calling it a couple hundred lines of code would make it a bit more
tangible. Not everybody actually prints out their rcfiles, or prints at
the same text size (I print N-up format on a postscript printer, in
itty-bitty text to conserve paper and put as much content before me as
possible).
Are these pages you refer to all incomplete recipes, or just recipes you
want to bypass (because of some message flagging or whatever already
accomplished)? There's a difference.
As that is an awful lot of #'s, I thought there might be an EOF command
that I could put into the procmailrc file to tell procmail that it
should ignore any text/cmd after the EOF command.
Generally speaking, you shouldn't have unwanted code in the rcfile, so why
should there be a construct to encourage the practice by making it easy?
Sure, over time, virtually everyone will have an archival recipe, or an
alternate condition line commented out, sitting at the ready to be
re-enabled when you're delving into an rcfile that is acting up. But to
permise your entire procmailrc on blocks of such things makes for messy code.
I suggest that you investigate the INCLUDERC= directive. You can put
collections of recipes into separate files, then include them where
appropriate. Your main procmailrc could get lightened up, and after you
test individual recipes, you could activate them by including them into
your live mailstream:
INCLUDERC=some_recipe_that_has_been_vetted.rc
The included file need only be the individual recipe (or really could just
be a few lines of code - it's parsed as if it were right there in the
parent rcfile and some people have creatively used this to implement
rudimentary recursive functions), so you don't mimic all your settings from
the top of your .procmailrc into the included rcfile, as those settings
have already been made.
Unfortunately using the 'HOST=' command on a separate line would stop
Procmail from continuing to use the valid recipes that are OK before the
HOST cmd?
Please run 'man procmailrc'. Unsetting host will terminate the procmailrc
at the point at which procmail parses the HOST assignment. Since procmail
is lineally processing the rcfile, it knows nothing of the unsetting of the
host until it goes to parse and process that line - which is AFTER it has
taken action on each line prior to it.
Obviously, you're using your live mailstream as a test rig, and the first
step to resolving your problem is to get you to kick that habit. Head to
the URL in my .sig and retrieve the sandbox setup there. My sandbox config
is a procmailrc that you'd pass to procmail invoked from the commandline
while piping a message to it (or using formail to burst a mailbox and pipe
that into procmail). If you find useful bits of code in the sandbox,
you're free to implement them into your .procmailrc.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail