Chris wrote:
> Bob Proulx wrote:
> > The -D option takes an argument.  If there is an argument following -D
> > then it becomes the argument to -D.  In the above the argument to -D
> > is -t due to it being positioned after -D.  That is not what you want.
> 
> Sorry for the late reply Bob, have had kind of a crisis with one of our
> canine children since Wednesday and haven't had much time to do
> anything. 

I am sorry to hear about your furry four legged family member.  Hope
it all works out okay.  I have been traveling as well and unable to
keep up.

> I've run your CL commands through an FP (still waiting for an
> FN) and here are the results:

Unfortunately I was not clear enough in my description.  Sorry but you
seem to have completely misunderstood.  Let me say things again in a
different way and perhaps maybe this will make sense.

The documentation says this:

       -D [area,...], --debug [area,...]
           Produce debugging output. If no areas are listed, all debugging
           information is printed. Diagnostic output can also be enabled for
           each area individually; area is the area of the code to instrument.
           For example, to produce diagnostic output on bayes, learn, and dns,
           use:

                   spamassassin -D bayes,learn,dns

           Higher priority informational messages that are suitable for
           logging in normal circumstances are available with an area of
           "info".

           For more information about which areas (also known as channels) are
           available, please see the documentation at:

                   L<http://wiki.apache.org/spamassassin/DebugChannels>

SpamAssassin scans the argument list from left to right.  If it
encounters the -D option then it scans forward for the next argument.
Whatever the next argument is that becomes the value of the -D
option.  If you want to set the debug area to foo then -D foo does
that.  If you want to set the debug area to bar then -D bar sets the
debug area to bar.

> chris@localhost:~/Test$ time spamassassin -d -t -D spamfp.mbox
> ^C

Think like a program.  Scan the argument list from left to right.

  -d, remove markup.  Okay.  Keep scanning options.
  -t, test mode.  Okay.  Keep scanning options.
  -D, debug.  Okay.  The -D debug option takes an argument.
  scan for the -D argument.
  spamfp.mbox, okay.  Debug mode is set to spamfp.mbox.  Keep scanning.
  No arguments found.  (If no files are listed then read from stdin.)  
  Read from standard input.

It is now reading from standard input.  It is waiting for you to type
in something.  It will wait forever.  Eventually you get tired of the
game and interrupt it with ^C.  That appears to have been at 2m34s.
If you had given it a file name on the command line it would have
scanned that file.  You did NOT give it a file name therefore it read
from your keyboard until you got tired and interrupted it 2m34s later.

With the debug area set to spamfp.mbox it will never have any
meaningful debug results.  Debug areas are "all" or "bayes" or
"config" or any of the other areas listed here:

  http://wiki.apache.org/spamassassin/DebugChannels

The "all" area is the default.  It is a useful -D value too.

> On the above command nothing seems to happen even though as you can see
> I let it run a bit over 2 1/2 minutes.

Since you failed to provide it with a file name it was reading from
standard input.  You provided spamfp.mbox as an argument to the -D
option.  The -D option takes an argument.  The very next argument
after the -D option is the value of the -D option.  I tried to say it
this way:

> > The -D option takes an argument.  If there is an argument following -D
> > then it becomes the argument to -D.  In the above the argument to -D
> > is -t due to it being positioned after -D.  That is not what you want.

Let me say this again.  And since it was missed again, again. :-)
The -D option takes an argument.  If you have something on the command
line after it then that will be the value of the -D option.

In Unix like operating systems we often use '<' and '>' file
redirections to plumb different files into stdin and stdout.
Those redirections take place in the command line shell.  They are NOT
seen by the program being invoked.  Therefore the only way to use -D
without providing it an option is to have it last in the argument
list.  The only way to have it last in the argument list but also have
it read from a file is to use a shell file redirection.

  spamassassin -d -t -D < mboxfile

The program never sees "< mboxfile" because that is a shell command
line directive to instruct the shell to attach mboxfile to the stdin
of the program.

If you want to tell spamassassin the command line program to read
mboxfile so that it opens the file itself then you must provide a
value to the -D option.

These are okay:

  spamassassin -d -t -D all mboxfile
  spamassassin -d -t -D all < mboxfile
  spamassassin -d -t -D < mboxfile

All of these are wrong:

  spamassassin -d -t -D mboxfile
  spamassassin -d -D -t mboxfile
  spamassassin -D -d -t mboxfile
  spamassassin -D -d -t < mboxfile

If it isn't understood why these wrong commands are wrong then ask
again because it isn't possible to move forward until there is
understanding of this point.

> The same with the next command:
> chris@localhost:~/Test$ time spamassassin -d -t -D *.mbox
> ^C

The error cascades through all of your other examples because you did
not understand that the -D option takes a value as the debug area.  If
you use -D then it either needs to be the last argument on the command
line or it needs to be provided with a value.  It is one or the
other.  Otherwise anything you put after it becomes the -D value.

Bob

Reply via email to