Re: INCLUDERC's vs Monolithic .procmailrc's
At 08:23 2000-09-26 -0400, Colin J. Raven wrote:
Can anyone comment on the reasons one should/should not use a single
"monolithic" .procmailrc as opposed to one .procmailrc *plus* several
Mostly, personal preference and technique. I find INCLUDERC to be a *LOT*
easier to manage than a monolithic .procmailrc
For instance, it is easier to put a bunch of spam rules in a couple of
files, and twit stuff in a couple of others, and mailing lists in a few
others, autoreplies in yet others. Modularizes everything. Makes brace
checking easier for really LARGE rule subsets (my spam rules are braced
within a NOT-SPAM exclusion rule for instance).
Need to disable a rule? comment out the include line. one comment, and
the whole rule (or series of rules, if you have multiple in an rcfile) is gone.
Need to copy and modify a rule that is almost exactly what you need? copy
the rcfile, edit the copy until it looks right (possibly even run it using
a testing-friendly .procmailrc alternate -- say, one that defines certain
variables so that the logfile and delivery directory are in a test subdir),
and when it looks right, you includerc it into your live environ.
If you have virtually nothing, then a "monolithic" file should be just fine.
When editing your config over a slow link, the smaller files mean less
scrolling about within a monolith looking for what you need.
OTOH, if you need to go global search-and-replace, a monolithic is easier
to manage without being familiar with a slew of external tools - you make
the changes to the file and save it, "poof" they're there across the board.
autoresponders in one, /dev/nulls in another and so on. Other than that, I
Perfectly valid way to use them, though I don't break them down solely on
delivery type. In many cases you may want to dev/null something after
checking for certain autoresponders, even if you normally might invoke your
dev/null before autoresponders. In that case, you have a separate
includerc that gets invoked after the autoresponder.
Part of my approach is that I have some lists I'm subscribed to which are
filtered BEFORE spam, but after twits (twits always takes priority, because
they're everywhere). When you're looking at a monolithic file, you have no
firm idea where you sit in it. When you're dealing with includercs, you
can be rest assured that if this rc is included BEFORE the spam filters,
then no matter where you are in it, the rule you're editing takes place
BEFORE the spam filters.
Same goes for autoreplies and vacation stuff (though I don't really do
vacation rules anymore) - filter LISTS, then, towards the end of my
filters, anything still unhandled is a personally-addressed message, and an
autoreply to it isn't going to cause grief to 100K of users on a PHP
mailing list or something.
Yea, this could be done in a monolithic file, but it's just like
programming - you don't dump EVERYTHING into one file, because it's
generally bad practice for anything other than very small quantities of
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
procmail mailing list