At 16:56 2002-01-18 -0600, David W. Tamkin did say:
Sean wrote,
| Why not use the arithmetic expressions afforded to you by a good bourne
| type shell?
Because it involves invoking a shell for something that procmail can do
without help.
Please provide an example of this. Something demonstrating procmail taking
an expression and assigning the results:
myscore=$myscore + $=
Doesn't work. Putting that within doublequotes (as my script demonstrated)
and subsequently processing it via the shell expression evaluator does.
If you weigh the previous score into each successive expression, don't you
rub the risk of zeroing out an individual test (say, you had a -20 running
score, and this recipe evaluated to 20, then ADDED the previous score:
.. other scoring operations
* $ $myscore^0
{
action
}
Would the action then not be executed?
It just seemed dynamically adding the score would lead to instances where
the score WOULD NOT be updated as a result of an intermediate test
resulting in a zero value, and subsequently not revising the value of the
carryover score.
Please, feel free to rewrite the given scruipt such that it works using
scoring for the carryover math, keeping in mind the potential for a zero
effect at some stage (yes, I realize that as presented, there was no
negative sum scoring going on - but I could see someone adding up black
marks against a message, and then subtracting based on other criteria that
negates the spam ranking).
| somescore=`echo $(( 12 + 3 ))`
That works only if /bin/echo is a shell script that hash-bangs a shell that
handles such expressions. If /bin/echo is a binary, you'll probably just
get "$(( 12-3 ))" back.
Solution? Force a shell:
somescore=`echo $(( 12+3 ));`
Ah, correct. I wasn't using that syntax within the script so didn't bump
into that - though I did in a way (see the formail at the bottom).
| * ? test $(( $myscore )) -gt $LIMIT
Again, if that's the only condition on the recipe, procmail needs no outside
help:
* $ $myscore^0
* $ -$LIMIT^0
The test operator is being done to force evaluation of the $myscore
string. That whole $(( expression )) thing is the process necessary for
the arithmetic evaluation.
Besides, even if you must do it that way,
* ? test $myscore -gt $LIMIT
Again, this doesn't evaluate the string:
/bin/bash: test: 10+12: integer expression expected
* $ $((myscore>LIMIT))
where ">" will serve as the requisite visitor from $SHELLMETAS.
to wit:
procmail: No match on "((10+12>20))"
or (if executed AS you wrote it -- without $ on the variables):
procmail: No match on "((myscore>LIMIT))"
| | formail -I "X-MyScore: $(( 1 * $myscore ))"
You're invoking a shell to multiple the number by one? How, except for
burning cycles, is that going to give different results from
| formail -I "X-MyScore: $myscore"
As indicated in the comments IMMEDIATLEY PRECEEDING THE FORMAIL INVOCATION,
for some reason this appeared to be needed to force an arithmetic
evaliation of $myscore (which isn't just a number, it's the longhand
expression:
0 + 10 + 30
(or whatever resulted from the previous scores)
As it happens, this is because I was for some reason, thinking that the
expression would be evaluated by the shell and it isn't - the addition of
the trailing semicolon will address that. The expression evaluator parens
are still necessary however:
| formail -I "X-MyScore: $(( $myscore ))";
---
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