procmail
[Top] [All Lists]

Re: Nested recipes... (sorry if this is sent twice.. )

2005-01-23 05:14:55
On Sat, Jan 22, 2005 at 07:34:19PM -0500, Glenn Sieb wrote:

Dallman Ross said the following on 1/22/2005 7:15 PM:

Leaving aside for the moment the awkwardly labarynthine construction
you have devised where the outside recipe with its lone condition tests
for ^TO_root@, leading to a nested recipe with its lone condition
testing for ^TO_root(_at_)wingfoot{an_unquoted_dot_isany_one_char}org;


Ok.. so more like:

:0
* ^TO_root@(wingfoot\.org|databasement\.org)
{
   :0
   * ^TO_root(_at_)wingfoot\(_dot_)org
   {
      LOG="(Wing Root Mail)$NL"
      :0
      .Wingfoot.Root/
   }
   :0
   * ^TO_root(_at_)databasement\(_dot_)org
   {
      LOG="(Databasement Root Mail)$NL"
      :0
      .Databasement.Root/
   }
}

Better, in that it probably at least works.  :)  It's okay, but
we can make it look prettier.

But now let's revisit the logic of the presentation.  The first,
outside recipe is completely superfluous.

Ok.. so you're saying it's not practical/feasible to do something
along these lines:

:0
* ^List-Post:(_dot_)*(_at_)freebsd(_dot_)org
{
   :0
   * ^List-Post:.*advocacy.*
   {
      LOG="(FreeBSD Advocacy Mailing List)$NL"
      :0
      .FreeBSD/Advocacy/
   }
   :0
   * ^List-Post:.*chat.*
   {
      LOG="(FreeBSD Chat Mailing List)$NL"
      :0
      .FreeBSD/Chat/
[snip]

Not exactly what I'm saying, no.  I'm not intending to
rule out what you call pre-filtering.  I'm simply wanting to
avoid needless repetition.

For one thing, think about how procmail is complying with your
condition requests: it is feeding the header to the condition's
regex for evaluation.  The header for this email posting that
I'm responding to has, for example, 93 lines on my system.
So now we have the procmail equivalent of:

   93 lines | egrep -i ^List-Post:(_dot_)*(_at_)freebsd[any-one-char]org

and assuming that passes muster, we run another recipe:

   93 lines | egrep -i ^List-Post:.*advocacy[followed-by-zero-or-many-anythings]

and assuming that evaluates true, write a log, and open another recipe to
save the message.  Or if it didn't evaluate true, run another recipe:

   93 lines | egrep -i ^List-Post.*chat[and-zero-or-more-anythings]

and ditto with the log and new delivery recipe.

Well, it's kind of okay, in that it works.  But it's, pardon the
expression, butt-ugly, and full of unnecessary extra things for procmail
to do.

Once you put your head into the mind-set of thinking through just how procmail
is seeing your code, and you start thinking about minimalism and the logic,
it gets easier, with practice, to improve the elegance and skill of what
you're trying to code.  And that feels good!  For you, I mean; procmail
doesn't really care.  Well, that's all I'm trying to get across, here:
a mind-set for improved, creative, more logical thinking.  You know,
there are usually quite a number of different ways to do things, any
one of which we might call "right."  But the right way to train your own
mind -- your programmatic rigor -- is to practice thinking the task through
with procmail's "eyes."  As for me, I'm never satisfied with my own
solutions, if you must know, and am always searching for ways to improve
them and learn more.  The approach may cause me mental restlessness, but
you'll never persuade me that it's not the right way, or Tao.  :-)


:) Ok.. So I'm taking from this that there's no sense in pre-filtering,
and there are no benefits therein? I was hoping there would be benefits
to grouping rules together, like speed or efficiency.. :-/

Grouping, and speed, and efficiency, and elegance, are all highly useful.
I didn't mean to imply otherwise.  I'm glad you've thought of some of
them!  What I was objecting to was extraneous effort,  but not the
core concepts.  Here are a couple of quick ideas for your task:

   :0
   * ^TO_root(_at_)\/(Wingfoot|Database)[.]org\>
   * MATCH ?? ^^\/[^.]+
   {
       LOG = "$NL$MATCH Root Mail$NL"

       :0
       .$MATCH.Root/
   }

-- 
dman

____________________________________________________________
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