Collin Funk wrote:
> > The problem is that the properties of an option have to be specified
> > in *two* places: in the long_options array *and* in the 3rd argument
> > to getopt_long().
> ...
> I wonder that the historical rational was for having the third
> parameter, the short options, in 'getopt_long'.
Probably because 'getopt_long' was designed as an extension of 'getopt'.
That is, the focus was on ease of adoption, i.e. to make it easy to
add long options to a program that was already using getopt().
> It feels like this
> information should just be derived from the long option array. That
> would mean you can't give conflicting option definitions like in your
> example.
Right.
And additionally, the way to specify the same information is different
in the two places: 'required_argument' in long_options is equivalent to ':'
in the short options string. [1] No one in their sane mind would design
an API like this when designing it *from scratch*.
And then, they noticed that they had forgotten to add a FLAGS argument
to getopt_long and dealt with it by adding special characters at the
beginning of the short options string ('+', '-', ':'). [2]
I thought that 'getopt_long' was an asset, because it is used by so many
programs. Now it feels more like a liability.
Bruno
[1] https://www.gnu.org/software/libc/manual/html_node/Getopt.html
[2] https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html
