long options with arguments require a [...] group that describes the argument
typically the argument name, optionally a default value
'[-][h:hasarg]:[arg:=1][n:noarg]'
On Tue, 10 Feb 2009 00:48:39 -0600 Terrence J. Doyle wrote:
> I've been exploring options with long names in getopts, and I've come across
> what appears to be a bug in optstring parsing. In optstring when a longname
> specification for an option without an argument follows a longname
> specification
> for an option with an argument, the option without an argument is not defined
> and is treated as a nonexistent option. Here's an example to illustrate:
> On another getopts issue, getopts --man still (as of ksh Version M 93t
> 2008-11-04) reports the wrong order for the optstring lead-in characters, :
> and
> +, when both are specified. I initially reported this in a reply to "A couple
> of
> things"
> https://mailman.research.att.com/pipermail/ast-users/2005q4/000742.html
> . Here's a recap:
:+ is the correct order
the --man document will be fixed
you can also specify this in the first [...] group that specifies other flags
too (preferable)
'[-+]...'
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
