Bug 4071 - invalid meta rules cause perl syntax errors with --lint
Summary: invalid meta rules cause perl syntax errors with --lint
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 normal
Target Milestone: 3.1.0
Assignee: Daniel Quinlan
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-08 16:54 UTC by Marc Horowitz
Modified: 2005-04-10 10:33 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Horowitz 2005-01-08 16:54:51 UTC 
I had this rule:

meta ANTIVIRUS_BOUNCE __SUBJECT_AV __BODY_AV

This is incorrect.  spamassassin --lint didn't give me much of a hint:

Scalar found where operator expected at (eval 52) line 334, near "} $self"
        (Missing operator before  $self?)
Failed to run meta SpamAssassin tests, skipping some: syntax error at (eval 52)
line 334, near "} $self"

lint: 1 issues detected.  please rerun with debug enabled for more information.

--debug didn't help any more.  The error message here could be much improved. 
As it was, I had to do binary search by removing parts of my user_prefs file to
figure out what was going on.
Comment 1 Bob Menschel 2005-04-07 23:13:23 UTC 
Confirmed in SVN. 

Similar problems with:
meta ANOTHER_ERROR  __FEED1 && __FEED2 || __FEED3 )
meta ANOTHER_ERROR  __FEED1 &&
Comment 2 Daniel Quinlan 2005-04-08 01:26:02 UTC 
see also bug 4037 and bug 3370
Comment 3 Daniel Quinlan 2005-04-09 23:25:35 UTC 
FWIW, I felt like fixing this one, but I'm not sure it really was needed for
3.1.0 (for future calibration).

how's this look?

Number found where operator expected at (eval 191) line 1, near "0 0"
        (Missing operator before  0?)
config: invalid expression for rule ANTIVIRUS_BOUNCE: "__SUBJECT_AV __BODY_AV":
syntax error
config: invalid expression for rule ANOTHER_ERROR: "__FEED1 && __FEED2 ||
__FEED3)": syntax error
config: invalid expression for rule ANOTHER_ERROR: "__FEED1 &&": syntax error
Comment 4 Daniel Quinlan 2005-04-09 23:25:50 UTC 
fixed in HEAD
Comment 5 Bob Menschel 2005-04-10 18:33:26 UTC 
> how's this look?

Looks good to me.  That first error message by itself doesn't help, but the
config error that follows tells us where the problem is. The other errors are
good without question.  As long as we see the name of the rule with the problem,
that should be all we need to track down how to fix the problem with the rule.
Thanks.
Comment 6 Daniel Quinlan 2005-04-10 21:36:36 UTC 
Subject: Re:  invalid meta rules cause perl syntax errors with --lint


> That first error message by itself doesn't help, but the config error
> that follows tells us where the problem is.

Yeah, shutting off warnings within the eval doesn't seem able to quiet
down certain errors like that one.  I tried both a "no warnings;" inside
a { } block and a local $^W = 0 and neither seemed able to quiet it
down.

If anyone has something that works, please let me know, but it's mostly
cosmetic.

Daniel
Comment 7 Loren Wilton 2005-04-10 23:57:20 UTC 
Subject: Re:  invalid meta rules cause perl syntax errors with --lint

As a user, looks good to me.

Also as a user and rule writer, I'm in favor of fixing this sort of thing as
soon as possible, given that the effort to fix it isn't huge.  Its a case of
multiplying manpower - the hour to fix the bug now vs the hour to fix it
some time in the future may save hundreds or even thousands of manhours of
other people's time, trying to track down syntax errors by divide and
concour.
Comment 8 Loren Wilton 2005-04-11 00:08:03 UTC 
Subject: Re:  invalid meta rules cause perl syntax errors with --lint

> > That first error message by itself doesn't help, but the config error
> > that follows tells us where the problem is.
>
> Yeah, shutting off warnings within the eval doesn't seem able to quiet

Actually it is a little helpful.  The second line tells you the failing
rule, and the first line maybe gives you a hint where in the rule the
problem is.