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:
$ function testopts
> { while getopts [-][h:hasarg]:[n:noarg] option
> do
> case "$option" in
> h) print "argument = $OPTARG";;
> n) print 'no argument';;
> esac
> done
> }
$ testopts --hasarg=yes
argument = yes
$ testopts -h ok
argument = ok
$ testopts --noarg
-ksh: testopts: --noarg: unknown option
$ testopts -n
-ksh: testopts: -n: unknown option
This occurs in the latest ksh Version M 93t 2008-11-04. But, it goes back at
least to ksh-q.
There are a couple work-arounds for this problem. You can simply put all
longname specifications for options without arguments first in the list of
specifications:
$ function testopts
> { while getopts [-][n:noarg][h:hasarg]: option
> do
> case "$option" in
> h) print "argument = $OPTARG";;
> n) print 'no argument';;
> esac
> done
> }
$ testopts --hasarg=yes
argument = yes
$ testopts -h ok
argument = ok
$ testopts --noarg
no argument
$ testopts -n
no argument
Or, if, like me, you're fussy about the order of options in optstring, you can
preceed longname specifications for options without arguments with []:
$ function testopts
> { while getopts [-][h:hasarg]:[][n:noarg] option
> do
> case "$option" in
> h) print "argument = $OPTARG";;
> n) print 'no argument';;
> esac
> done
> }
$ testopts --hasarg=yes
argument = yes
$ testopts -h ok
argument = ok
$ testopts --noarg
no argument
$ testopts -n
no argument
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:
When I type:
$ getopts --man
the following appears regarding including + and : in optstring:
If the leading character of optstring is +, then arguments
beginning with + will also be considered options.
A leading : character or a : following a leading + in optstring
affects the way errors are handled. ...
It's been my experience that :+ at the beginning of optstring produces the
desired results as you indicate above. However, getopts --man seems to say,
incorrectly, that +: is the sequence.
Terrence Doyle
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
