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
> "INCLUDERC" files?
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 
EVERYTHING.
---
 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
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail