From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11851 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getopt() not exposing __optpos - shell needs it Date: Mon, 28 Aug 2017 11:28:44 -0400 Message-ID: <20170828152844.GY1627@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1503934140 803 195.159.176.226 (28 Aug 2017 15:29:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Aug 2017 15:29:00 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11864-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 28 17:28:55 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dmLy9-0008GX-BT for gllmg-musl@m.gmane.org; Mon, 28 Aug 2017 17:28:53 +0200 Original-Received: (qmail 9513 invoked by uid 550); 28 Aug 2017 15:28:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9495 invoked from network); 28 Aug 2017 15:28:57 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11851 Archived-At: On Mon, Aug 28, 2017 at 12:18:57PM +0200, Denys Vlasenko wrote: > I am using getopt() in busybox hush shell. > "unset" builtin, for example: it takes -v and -f options. > This works fine. > > However, POSIX requires that shells has a "getopts" builtin: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html > > It is basically an API binding to access getopt() in the shell code: > it uses OPTIND and (in bash) OPTERR on entry, returns a single-char > variable on return and updates OPTIND and OPTARG. Sounds familiar, right? > > When I try to do that (use getopt() to implement "getopts"), it hits a snag. > Unlike normal getopt() usage in C programs, where it is called in a loop > with the same argv[] array until parsing is finished, > when it is used from "getopts", each successive call will (usually) have > the same argv[] CONTENTS, but not the ADDRESSES. > (The reason is in how shell works: it re-creates command arguments just before > running a command, since there can be variable substitution, globbing, etc). First, some background out of the spec to establish what is supposed to work and what's not: If the application sets OPTIND to the value 1, a new set of parameters can be used: either the current positional parameters or new arg values. Any other attempt to invoke getopts multiple times in a single shell execution environment with parameters (positional parameters or arg operands) that are not the same in all invocations, or with an OPTIND value modified to be a value other than 1, produces unspecified results. What this means is that, when you use getopts(1), you need to either use the exact same arguments (as you said, *string contents*, not likely to be the same argv[] pointers) or reset it with OPTIND=1. It seems to me that the easiest, fully-portable fix is just the obvious quadratic-time solution: on each run of getopts(1), reset getopt(3) to the start and call it ++N times. A less costly portable solution would be to track the number of calls since optind advanced, and only reset that far, so that the number of getopt(3) calls is only quadratic in the number of 'flag-type' options that are stuck together in a single argv[] entry. Rich