On Thu, Apr 30, 2009 at 4:16 PM, James Carlson <james.d.carlson at sun.com> wrote: > Jason King writes: >> After lots of reading, rereading, parsing, and reparsing, I believe >> using getopt_long(3c) to process the arguments, with '+' being the >> first character of the option string, gives the desired behavior >> (without breaking any standards). > > Yep; I think you're on the right path.
Upon further investigation, this will not allow optional long arguments (I thought it did), so now I'm at a loss, and my head hurts from trying to decipher what is, what isn't standard conforming. So, I will simply ask, is there any facility in Opensolaris that supports: 1. Long and short options, where there might be long options that don't have corresponding short versions 2. Long arguments that can have optional parameters of the form --option=FOO, or --option but not '--option foo') 3. Long arguments that can have mandatory parameters of the form --option=FOO or --option foo 4. Doesn't break POSIX or SUS standards. If so, what is the correct invocation to achieve this, because I seem unable to figure it out. getopt_long(argc, argv, "+......", longopts, &indexptr) apparently requires all parameters to long options as mandatory. I.e. 'ls --color' does not work. My understanding is getopt_long(argc, argv, "....", longopts, &indexptr) where the first character is not '+' allows argument reordering and is therefore not posix compliant (but does allow --option[=FOO]. It looks like "-....." for the short option string might, but at this point I've given up trying to understand the getopt_long manpage as everything I think i've understood it, I find yet another case to prove me wrong, so please anyone who actually understands this, please comment.
