[illumos-Developer] Any standards aliens (or anyone else) want to comment on bug 449?

[Joerg Schilling]

getopt_long*() it not part of the standard....

Jason King <jason.brian.king at gmail.com> wrote:

> So I decided to take a look at Bug 449
> <https://www.illumos.org/issues/449> getopt_long_only(3c)
> returns wrong value (which itself is a copy of *solaris bug 6835846).  Doing
> a little digging though, I'm not so sure it's a bug as much as a lack of
> feature, but would like some feedback...
>
> The problem (I think) is that there is lack of sufficient flexibility in the
> getopt_long_* (3c) interfaces.  Specifically, there doesn't seem to be a way
> (from what I can tell -- this is where I'd like feedback) to specify
> --option style arguments (but NOT -option ala X style arguments) while ALSO
> allowing optional option arguments (i.e. --option=foo or --option).
>  getopt_clip(3c) allows for --option style long arguments and traditional
> short arguments, but does NOT allow for optional option arguments.
>
> Using the example test case in the bug, the problem with -lc foo and -cl foo
> is that '-cl' is interpeted as '-classify', thus returning the equivalent -F
> short option, when really what is desired is to disallow -option style
> arguments.
>
> I will note that based on documentation, it appears linux only supports
> --option and not -option, of course caveat hackor when relying on linux
> documentation.

Regardless of what implementation you use, getopt_long*() is full of design 
flaws. My code uses a different, older and much more mature option parser.

The idea fron GNU to permit abreviated long options is a missdesign as a result 
from not understanding the problems in option parsing correctly.
The biggest problem with e.g. GNU getopt_long is that it is unable to correctly 
deal with option names that start with the same substring and that have 
parameters. If you have a typo in the commandline, it will just feed one of 
the options with a nonsense string parameter that contain the typo.

If you have a program like mkisofs that has many similar option names, this 
results in unparsable results. The only way to deal with such problems is to 
require space between such options and their arguments and of course to never 
permit abreviated long options. This is flag selectable with my option parser
for every single option name. Note that options that have optional arguments 
are options that require not to have a space between option name and argument.

If you like a manageable option parsing system, I recommend the 
getargs()/getfiles() series of functions from libschily. This option parser is 
older than even the single char option only getopt() function and it implements 
typed and flagged options. After converting mkisofs from getopt_long() to my
getvargs(), the code from mkisofs shrinked by 1000 lines and missspelled 
options now are correctly detected. I did write the getvargs() variant of my 
option parser in 2006 to make it easy to convert mkisofs that implements more 
that 170 base options and many aliases and that have been in an array of 
structures for getopt_long() before. The basic getargs()/getfiles() series of 
functions already exists since 1980 and permits long options since then. 
getopt() was written later by AT&T for SVr2 and did only support single char 
options. 

BTW: combined single char options that have parameters are incompatible with 
the POSIX base CLI spaecs and cannot be properly and reliably parsed by a clean 
general purpose option parser. If you like to get sample code on how to 
implement compatibility to the ill-designed CLIs from the mid 1970s, I 
recommend to have a look at the function docompat() from star.c. docompat() 
works because there are only a few such options in tar that are handled 
different by reordering the the arg vector. GNU getopt() claims to be able to 
handle such cases, but it secretly rearranges the arg vector resulting in 
strange effects in programs that are not prepared for such a argv modification.



Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily