Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: Possible bug in getopts when required argument is not supplied Date: Fri, 13 Nov 2015 15:19:49 -0500 Organization: ITS, Case Western Reserve University Lines: 36 Approved: bug-bash@gnu.org Message-ID: References: <535058272b68c9459882c6bd4565b428.squirrel@webmail.oplink.net> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1447446011 19060 208.118.235.17 (13 Nov 2015 20:20:11 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: Griff Miller II , bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <535058272b68c9459882c6bd4565b428.squirrel@webmail.oplink.net> X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.564645E7.01C1,ss=1,re=0.000,fgs=0, ip=173.191.69.108, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: d1efeb4a4bf44b4ca35d2ca5ff201a30 X-Junkmail-Whitelist: YES (by domain whitelist at mpv2-2015.case.edu) X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.564645E7.0302,ss=1,re=0.000,fgs=0, ip=173.191.69.108, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: 32db463bc012798a8e3b9e36268ae2c2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.227 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11879 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/