FWIW... first impressions while testing your library

[marcastel]

Simply food for thought as I test your library :-)

1. The argument to short options MUST be preceded by whitespace -- in my experience, POSIX compliance here is essential.

2. Would be nice to allow short options to be incremented when repeated, like ssh -vvv.

   ./demo -fff # Testing ssh(1)-like verbosity increment

   flag: 1
   string: unset
   argc: 1
   argv[0]: Testing ssh(1)-like verbosity increment
   argv[1]: NULL

   I don't mean flag ++ in the demo application but rather the addition of a type enum which could indicate , for instance NUMBER, STRING, BOOLEAN, TOGGLE, and... INCREMENT for the point under scrutiny.

3. The header supports the end-of-options marker (--) but delegates responsibility of segregating option arguments from regular arguments to the implementation code.

   I sure understand this grows the complexity of getopt.h, however POSIX philosophy here is critical too, even if there has been a growing trend for implementations in other programming languages to place options anywhere on the command line, especially recently at the end.

   A UNIX command is, and should remain: <command> [ <options> ] [ '--' ] [ <arguments> ]

[hippie68]

Thank you for your feedback - it was an interesting read!

1. I know about that document, but understand it differently: 12.1 - 2.a: "However, a conforming implementation shall also permit applications to specify the option and option-argument in the same argument string without intervening characters". Please tell me what you think.

That said, in general, I try to closely follow these recommendations: https://nullprogram.com/blog/2020/08/01/

2. I have written a larger library, https://github.com/hippie68/optparse99, which implements those features. It is not by any means perfect and I'm sure there is much found to be criticized. However, I when I wrote it, I noticed that the approach of implementing additional features quickly gets out of hand, so I created this library (getopt) as a simpler alternative. I am reluctant to add anything more than there is now, though I'm open to suggestions. In this case I think it's not a big deal to add those features manually as required. Apart from string-to-number conversion, it should be mostly 1-liners.

3. That may indeed be worth implementing as an optional feature for those who need it, thanks!

[marcastel]

Hi @hippie68 That was quick :-)

I have written a larger library, https://github.com/hippie68/optparse99

I hadn't spotted your optparse99 project and will give a try.

I fully understand and concur to your approach... except perhaps to your understanding of the POSIX requirements for short options.

I know about that document, but understand it differently: 12.1 - 2.a

In my understanding, the paragraph states that you don't need two command line arguments for a short option that accepts an argument, it doesn't say that you can concatenate this option with other options.

Further, my reaction is field experience over the years where I have been confronted to ambiguous situations relating to this very point which have sometimes raised critical issues in production.

That said, in general, I try to closely follow these recommendations: https://nullprogram.com/blog/2020/08/01/

I wasn't aware of this article. I will give it a read. At first sight it says... be POSIX compliant (except for short option spacing) and don't do like all the non compliant projects out there (i.e. Linux (sic), Bash and all *sh except the KornShell, Python, ...).

Regarding CLI option parsing, we essentially have two utilities to help us lint our developments: the venerable sh(1) on POSIX-compliant UNIX systems (and macOS is still one of them), and the KornShell getopts built-in (in the last official release of the AT&T ksh executable (ksh v93u) before David Korn and co were fired). I will try to spare some time to explore the behaviour of examples in the blog article with ksh.