On 11/13/15 11:13 AM, Griff Miller II wrote:
> Note that in the last run, getopts does not detect that nothing was passed
> via -a, even though -a requires it. Instead, it thinks the next switch
> (-b) is the value of -a. Perhaps this was a conscious decision, so that
> values starting with '-' can be passed, but it's a more of a surprise to
> the developer than discovering that the user can't do e.g. ./myscript -a
> -my_a_val . Can this bug, if it's deemed a bug, be fixed, else the
> manpage updated in the getopts section to make it clear what is going on?
It is not a bug. An option argument is the next command line argument
following the option, regardless of whether or not it begins with a
hyphen. In fact, there are very few restrictions on the characters that
an option argument can contain, period.
> If there is a requirement that the user be able to have optargs that start
> with '-', maybe not allow OPTARG be one of the options in the first
> argument to getopts ($opts in the above script)?
This sounds needlessly restrictive. Consider a shell script that is a
front end to some other command or set of commands. It takes its own set
of options, as well as an additional option (-W, say) that allows users to
specify options that are passed directly to the invoked program. (This
is kind of like what gcc does with its -W option, but simpler).
Artificially restricting the option arguments to -W would reduce the
general usefulness of getopts.
In your case, it's probably enough to check $OPTARG and throw an error
if it begins with a hyphen.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
