Re: option group questions

[Joachim Banzhaf <joachimbanzhaf compuserve de>]

Hi,

Am Sonntag, 8. Juli 2007 20:40 schrieb Robert Pearce:

> > But this causes problems:
> >
> >   testprg -v 0 -h host -p 9
> >
> > No complaint about 0. V is not supposed to take an argument?
>
> The default assumption on Unix is that any argument that isn't an
> option or an argument to an option is part of "the rest of" the
> program's parameter list. So for instance, the ls command has an option
> -l that doesn't take any arguments, but it's still valid to type "ls -l
> fred" because ls expects a list of directories to list.
>
> Because some programs also allow intentional mixing of options and
> parameters, the "getopt" approach is to ignore things like the "0" in
> your example, leaving them for the program to handle. There is an
> option to change that behaviour, but it's a choice between stripping
> out all the options and leaving a parameter list, or stopping
> processing options when a parameter is found (so the program can handle
> it). I would expect Glib::options to behave much the same. I certainly
> wouldn't expect it to produce an error in your example - if that
> condition is an error then it's explicitly your responsibility to
> handle it.

So, the 0 should appear in argv after parsing. That sounds logical. I'll 
check.

> >   testprg -p9
> >
> > Docs indicate the space between opt and arg is mandatory. I dont like
> > that. Is it configurable?
>
> I can't answer this, but it's common to allow "grouping" of
> single-letter options (e.g. "ls -alR fred") so making the space
> mandatory avoids confusion. That said, behaviour of getopt in this
> instance is that any option with a mandatory argument causes the rest
> of the string to be treated as argument.
>
> So for instance, if you typed "testprg -vh host -p 9", that's valid,
> but "testprg -vhp host 9" would be interpreted as "testprg -v -h p host
> 9", i.e. the 'p' becomes the argument to '-h' and the 'host' and '9'
> are stray parameters.

It seems Glib::Options is more relaxed on parsing than I expected.
I like having options first and additional arguments following and not mixed, 
because that allows grouping single letter options without argument with one 
option that takes an argument which can follow immediately or separated by 
whitespace (like gnu tar does it). Allowing intermixed nonoption arguments 
makes that ambiguous.

Has anybody example code with glibmm that enforces/enables this tar compatible 
behaviour?
Or a first idea on how to do it (with glibmm)?

> >   testprg -v -p 9
> >
> > No complaint about missing -h option. How can I define an option as
> > mandatory?
>
> Surely the term "mandatory option" is an oxymoron!

:-)

> If you require the user to supply an option, then getopt makes that
> your responsibility. I'd imagine Glib::option does the same.

Ok, that should be easy. Initialize the option with an invalid value and check 
after parsing will do that. Just hoped I could tell Glibmm with some flag to 
do this for me.

> Hope that helps,

Yes it did! Thanks.
It seems, I have to make my MainOptionGroup class considerably more 
intelligent to make it do what I want.

Joachim