procmail
[Top] [All Lists]

Magic macros... (Re: Outbound mailing lists)

1996-07-04 17:47:41
Stan Ryckman <stanr(_at_)sunspot(_dot_)tiac(_dot_)net> wrote:
  * ^TO_AllArchitects

Just *why* have these macros been defined without requiring some
sort of separator from what they follow?  This bizarre syntax
makes the syntax highly confusing, perhaps even ambiguous.  What if

It's not as ambiguous as you think, since the leading caret (^) is
a mandatory part of the macro.

As to the why, well, in the beginning, there was only one:  ^TO
It started life as being part of some other utility not written
by me, and it seemed like a good idea at the time :-).
Anyway, the reason why there aren't any fancy delimiters for
these macros is because they were meant to be used by people that
are intimidated by regular expressions and magic characters, and because
using special delimiters would introduce yet another pair of magic characters
you'd have to watch out for (when writing conditions).

you want something starting with "TOA"? or what if you want something
that was sent to _AllArchitects but have "TO" and not "TO_"?
[...]
but the magic of "TODAY" matching any "To: DAY" is bizzare IMHO.
And 'TO.*DAY' makes perfect sense to me.

Note that you forgot the caret as part of the macro.  Adding that,
you'll see that the examples you came up with become pretty unlikely.
I personally have *never* come across a case where it would have
taken special precautions to prevent the macro from being replaced in
the six years of procmail's existence.

Matching for "^TODAY" is something you rarely do (definitely not
in a mailheader).  And if you ever need it, simply replace it
with "^()TODAY" or something similar.  Besides, matching is
case insensitive by default, so you can (and most people do) use
lowercase in which case the macros will never become a problem.

Or if you prefer, create a variable $TO, used in the string as "${TO}"
if adjacent to something that looks like more of a token.  Just pleases

That is already supported, but completely userdefined.

Otherwise, how is anyone to know just *what* characters up front
might trigger a macro?  Yes, I can remember TO and TO_ ... but when
the next procmail comes out with more such "invisible" macros,
weird things will happen.

There will not be and is not a flurry of such magical macros.
Many people have asked for ^FROM, but it has never made it in, and it
is not policy to extend the list in any way.

^TO and ^TO_ already end in an expression that is better than ".*"; adding
".*" after them seriously weakens their function.

How does this weaken them?

It causes it to match *more* than you wished for, hence confusing you.
Incidentally, judging from this question, *you* are amongst the intended
target audience of the ^TO and ^TO_ macros.  People that can answer this
question themselves do not need these ^TO or ^TO_ macros.

(other than by slowing them down, perhaps,
and usually who cares about that?)?

If you run a large site, where a lot of mail arrives, then procmail
is invoked more often than you'd like.  You'd probably gladly accept
all the efficiency you could get.
-- 
Sincerely,                                                          
srb(_at_)cuci(_dot_)nl
           Stephen R. van den Berg (AKA BuGless).

"To err is human, to debug ... divine."

<Prev in Thread] Current Thread [Next in Thread>