At 15:14 2002-12-30 +0100, poff(_at_)sixbit(_dot_)org did say:
Ah I see, I just sent a mail asking how to do the domain thing as below, I
still don't undertand how it works... but the MUSER is actually the FROM
in the cases when I want to use it:
Uh, then why have MUSER and FROM?
UserName <login>
So, where does _MUSER_ fall into this? As I indicated - the original
recipe you offered generally resulted in a null MUSER value.
Is when it's sent from within the system, so the FROM won't have a @ and
the FROM itself should hopefully be the username, this bit isn't needed in
my case.
You are mixing terms again - in your examples, FROM contained the full
address, so why are you saying it shouldn't? Perhaps you mean MUSER won't
have the @ ?
> # domain
> :0
> * FROM ?? @\/.*
> {
> DOMAIN=$MATCH
> }
Like I said - thanks! This works but I still don't understand why :(
What's with the ?? ? why isn't there a \/ before the @?
'man procmailrc' - ?? is used to perform the conditions against the
contents of a variable, instead of against the message headers or
body. Since we've extracted the address into the FROM variable, we want to
perform the domain portion extraction against that.
Do you really want the "@" in the MATCH? I thought you wanted the domain
in the variable - the "@" appears in the expression on the LEFT hand side
of the match operator, which says "find the text up to and including the
'@', THEN start the match operation". Well, actually, I don't recall
having seen a spec statement of what the variables were supposed to
contain, I just inferred it from what your original recipe managed to do
when it managed to do something.
AWK I always imagined mightily faster than the "bloat" of perl - in fact
it's the reason I started messing with it when I wrote a script for doijng
IME, Perl is much faster. Could be issues with versions of specific
tools. Different tools have different ideal purposes.
something mundane like parsing /tmp dumps in perl - which was SLOW and
then wrote it in awk which was very very fast - mainly as I was using
arrays and file handles... But then, I don't know much about all of this
;)
Sloppy code can run like dirt. Code which is invoked frequently should be
optimized. As an example, in a 3-D rendering system, you could spend time
improving the code within a matrix function tenfold, but if you improved
the speed of the underlying multiplication function by a mere two CPU
cycles, you might see a huge improvement in overall program performance,
because that's two cycles each time the function is called from anywhere,
and it's going to be called many times from the matrix function, as well as
elsewhere. IOW, choose where you optimize - for stuff called once in a
blue moon, it may not make sense to spend the time cleaning the code up to
save resources - but if it's called on many messages - or virtually every
one - then it makes lots of sense to do it right the first time out.
Luckily for me (he says :) this system is running dual 64bit alphas with a
"combined processing power" (I don't write this stuff) of 21.1 glfops -
That is never a good reason to waste cycles - everything you needed to
accomplish was capable of being done 60 times faster -- and, more
importantly - accurately.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail