SA Bugzilla – Bug 3370
Further enhancement request for --lint / check for broken meta rules
Last modified: 2006-08-03 11:14:21 UTC
--lint might not be the proper place for this, some of it might but not all. Those of us who create a lot of custom rules find ourselves checking for simple human errors that can cause a ruleset to go bad. The following is a list of suggestions combined by our SARE group, order is set by importance: Dumb rule checking, could lint check for a stupid rule like: body FOO /(?:this|that|them|these||those)/ That double || will fire on everything and can not be valid in a rule. A few of us have suffered from this in the past. Asking for this because we are human and make mistakes. Some other examples of this include: /(?: |)/ /(?:| )/ or could be: /(?: |foo|bar)/ /(?:foo|bar| )/ Other possible lint warnings: Unknown meta rule warnings (meta rules that include rules that are possibly mis- spelled or missing) meta FOO (BAR_DOES_NOT_EXIST && NEITHER_DO_I) score FOO 1.0 This produces no errors. Missing Descriptions - I object to this but it was brought as a possible improvement. I personally do not use any descriptions for my own rules, so if something like this does make it in, would it be possible to turn off warnings on something like this? Config like: lint_ignore_descriptions 1 Missing scores - This might be helpful, but many times I write a simple rule to run against mass-check and I don't need a score set until I figure out how the rule will perform. Could the error messages from --lint be improved? Maybe check for common mistakes like not escaping @ I'm not educated enough with perl to know what @ is used for, so maybe this alone would help some folks. Take the following rule: body TEST_FOO /the@man test/ It produces the folling lint error: LINTING RULESET Failed to compile body SpamAssassin tests, skipping: (Global symbol "@man" requires explicit package name at C:\Perl\Site\Etc\Mail\SpamAssassin/NEW_RULES_UNDER_TEST.cf, rule TEST_FOO, line 1.) This does tell the filename the problem exists in, I thought is was doing something different, either way, that was reported to me and needed to be included. Thank you
there's actually a linting script in masses -- "lint-rules-from-freqs". right now, it accepts freqs data on STDIN and does some linting; but it should probably be modified to not always require freqs, since most of its linting code does not use that anyway. It already does a fair bit of warning about missing descriptions, etc., and looks into the rule code for issues, so would be the best place for these. actually, I think it may also catch missing meta rules (Theo, didn't you add that a while back?) (also we're already getting complaints about spamassassin --lint being too strict ;)
Using 3.0.1 --lint does not identify broken meta rules. meta TEST_FOO1 (MY_META_TEST01 && __FOO_BAR_BS) score TEST_FOO1 1.1 Most of what I brought up when I opened this ticket can be ignored but I think this issue is more important and not going to cause people to complain about lint being too strict. This is an important lint item which is not performed.
move bug to Future milestone (previously set to Future -- I hope)
I have modified make test to handle meta rules with missing or disabled dependencies. meta rules with syntax errors still has to be addressed somewhere.
see also bug 4037 and bug 4071
Daniel, I haven't looked into this much, Can this make test be used to test 3rd party rules? Is it included with 3.1? If so, I'd be happy to close this ticket, but this issue hit me again today so I'd love to have some way to catch my stupid user mistakes.
Should I close this ticket? I understand it might not be practical for this feature, since it's built into your t test's it is only handy for those of us writing 3rd party rules. I've since built my own meta dependancy walker so I no longer need this built in.
well, the meta dependency tree tracing in bug 3109 would make it reasonably simple.
'spamassassin --lint -Dinfo' will now report broken meta dependencies...