Re: option group questions



Hi Joachim,

Nobody else has answered, so I'll chip in, even though I've not used
Glib::options -- I tend to use the unistd getopt, but the documentation
for Glib suggests the philosophy is similar.

On Wed, 4 Jul 2007 13:37:57 +0200 you wrote:
> 
> First goal is a program, that accepts an optional boolean option v without argument and mandatory integer and string options p and h.
> 
> Wellformed commandlines seem to work as expected:
> 
>   testprg -v -h host -p 9
> 
That's a good start

> 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.

> 
>   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.

>   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.

Hope that helps,
Rob



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]