http://bugzilla.spamassassin.org/show_bug.cgi?id=3340
------- Additional Comments From [EMAIL PROTECTED] 2004-10-01 22:24 ------- > But -D in general throws TONS of messages whether anything is broken or not, > making it virtually necessary to then write a filter script to see if any of > those messages actually were any sort of lint error or warning Justin's suggestion is elegant. I'm +1 for it. Daniel, I'm confused about the new command line switches that you voted +1 for. As far as I can tell Justin's proposal works with no new command line switches, changing only what happens when you used both --lint and --debug, and handling all the output in a modified t/basic_lint.t test. Did I miss something here? Loren, the idea is that --lint outputs its warnings as debug messages. You use the -D switch (which is the same as --debug, see the man page) to see the lint warnings. Hence --lint by itself shows you lint errors, -D or --debug by itself shows you tons of debug messages but lint is not run, and -D or --debug along with --lint (order doesn't matter) shows you the lint errors and tons of debug messages which include the lint warnings. The only way to see lint warnings is along with tons of debug messages, but most of the time you just run t/basic_lint.t to check it so you don't have to wear out your fingers writing one line of command to pipe the output through grep. t/basic_lint.t would have the filter in it that you are worried about having to write. As I said, it is an elegant solution, with no new command line options. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
