bogotune patch for -D option.

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> The behavior of the -n and -s options changed when option parsing was
> changed to use getopt().  AFAIK, using getopt() precludes the old
> behavior, i.e. -n ham1 ham2 -s spam1 spam2.   If you know differently,
> let me know.  In any case the man page now describes the current
> behavior.

As we're using GNU getopt, this would apply:

|  By default, getopt() permutes the contents of argv as  it  scans,  so  that
|  eventually  all  the  non-options are at the end.  Two other modes are also
|  implemented.  If the first character of optstring is '+' or the environment
|  variable  POSIXLY_CORRECT is set, then option processing stops as soon as a
|  non-option argument is encountered.  If the first character of optstring is
|  '-',  then  each non-option argv-element is handled as if it were the argu-
|  ment of an option with character code 1.  (This is used  by  programs  that
|  were  written  to  expect  options and other argv-elements in any order and
|  that care about the ordering of the two.)  The special argument "--" forces
|  an end of option-scanning regardless of the scanning mode.

This opens two possibilities, #1 is incompatible with 1.0.0 behavior and
thus would be strictly 1.1.0 stuff, so I suggest #2 (patch attached):

1. REQUIRE_ORDER aka. POSIX behavior, i. e. adding '+' as first
   character in the optstring. In that case, bogotune would have to
   parse -n and -s and files manually; getopt would then read up to the
   -n ham1, return 'n' and optarg == "ham1", and leave "ham2" "-s"
   "spam1" "spam2" starting at argv[optind].

2. RETURN_IN_ORDER aka. argument hack, i. e. adding '-' as first
   character in the optstring, that still allows options to appear after
   arguments. In that case, getopt would return this sequence:

   return_value    optarg
   'n'             "ham1"
    1  (= '\01')   "ham2"
   's'             "spam1"
    1              "spam2"

   With empty argv.

BTW, the run_type stuff in bogotune is way ugly. run_type should be
passed down as argument, rather than being a global variable.

Note I don't use bogotune, so I'd need someone to test the attached
patch. With bogofilter 1.0.0 - 1.0.2, you'd have to give

bogotune -n ham1 -n ham2 -s spam1 -s spam2

with the attached patch,

bogotune -n ham ham2 -s spam1 spam2

should work again. I think this is a compatible change and thus suitable
for bogotune 1.0.3.

-- 
Matthias Andree
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bogotune-arguments.diff
Type: text/x-patch
Size: 4041 bytes
Desc: allow -n ham1 ham2 -s spam1 spam2 again
URL: <http://www.bogofilter.org/pipermail/bogofilter/attachments/20060327/7e57b7a9/attachment.bin>