[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170828152844.GY1627@brightrain.aerifal.cx>
Date: Mon, 28 Aug 2017 11:28:44 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getopt() not exposing __optpos - shell needs it
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
