Re: mailgw argument parsing

Hi Ralf:

In message <[email protected]>,
Ralf Schlatterbeck writes:
>On Tue, Nov 22, 2022 at 01:34:08PM -0500, John P. Rouillard wrote:
>> 
>> Also because there are still distributions that package Roundup, not
>> everybody reads the upgrading doc as well as they should.
>> 
>> So I would like to keep the -C to set the default class for -S.  So if
>> the -S argument doesn't have a "class." prefix, it uses the class set
>> by -C.
>
>This is not possible for the following reason:
>- A single -C can be followed by multiple -S options (we test for this!)
>- There can be multiple -C options
>- With optparse we cannot know which -C belows to which -S options
>
>Therefore I would prefer to make -C an illegal option. Better fail early
>than make a mess of incoming emails.

Crap it looks like the help text in mailgw disagrees with the man
page. So we do have docs that allow -C -S -S -S -C -S. That
was never intended.

IIRC I wrote the -C/-S implementation (poorly as it turns out) in 2002
to support my use case withmultiple nosy lists. In any case, what I
intended was a single pair of:

  -C -S

or a bare

  -S

(-C msg as the default).

I see you made some changes in 2011 to that to support multiple -S
options. I assume this was to allow setting multiple params without
using ';'? I would like to support one -C option (to set the new
default to something other than msg), so the simple/original case
continues to work.

But I really don't have a leg to stand on anymore since the program
documents multiple [-C]/-S segments are valid.

So I withdraw my objection. Feel free to update the docs (include the
man page please) and merge. I agree once you get more than one set of
-C/-S pairs in place, your -S class.prop=value is much cleaner.

Have a great week.
--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.