Re: Possible bug in getopts when required argument is not supplied

[Chet Ramey]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/