From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11857 Path: news.gmane.org!.POSTED!not-for-mail From: Denys Vlasenko Newsgroups: gmane.linux.lib.musl.general Subject: Re: getopt() not exposing __optpos - shell needs it Date: Tue, 29 Aug 2017 14:47:13 +0200 Message-ID: References: <20170828152844.GY1627@brightrain.aerifal.cx> <20170829122014.GZ1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1504010914 12460 195.159.176.226 (29 Aug 2017 12:48:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Aug 2017 12:48:34 +0000 (UTC) To: musl Original-X-From: musl-return-11870-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 29 14:48:26 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 1dmfw8-00022a-3N for gllmg-musl@m.gmane.org; Tue, 29 Aug 2017 14:48:08 +0200 Original-Received: (qmail 17807 invoked by uid 550); 29 Aug 2017 12:47:46 -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 17743 invoked from network); 29 Aug 2017 12:47:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hAtpuizDKyqB74GOGaNKpTkDgO0NxDtycFjrKn3gCE4=; b=L168Y8yhKZsohKx5wm0yYLaS0eJlctgUYMj1RdSIwx92FtBDbC/DowEUE22XebNRrp 3VLKnjNjljPfyg5XpZruaIf8dK96jB563jcJ20kpYbFvXT1NqUioyqrdvIdgZMCip841 BUMk0BcHE7xUdIc73Q8Hs8xBgRDMimkbIjxhDzqk1RWQQVh9g/WjZktaStyHqyfAD8yh vdVsv8ZOZJtIW8tV+xOxUJQ+PVAmnwLMAv/I726tcLHwX6vwHGRersedBeYtfnK0BZiY HFtC/Ah1Gy/TSL1TYTUAaO3nr/iNuMmUzzUobe6R5S0L1vRWvvkqlsxUQovonBTKb3bI HIyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hAtpuizDKyqB74GOGaNKpTkDgO0NxDtycFjrKn3gCE4=; b=n/McUQ0bqP5aMwMqJ9O0ujJa/4WCAkua4IhgKqpXUos8gAjH9f59Df/4L/foXbqmSg Gj9MCCnirfAvfb7J33l1T8LoSpnMijiz8iysfFbQVQ7w0g8bC5VkGwlc1/uIEwUVAWQL 2XKt+tK7qGLE4pANHUpJG3eAg/bqMEgYgI+L3lMwO5muBFhi/KMmFGFbAQ5ySST5ZOmc 74YujycrOAwUzvbzq3IQ5fg+4WtUtPW2A4NiniblcfDwkYYur6Zc5cqS2ltVGJxiqZ9E vJfuJliGjLOEhAJEsAkVRCvCxb1cUrzBopAKT+DVzjd3XYFbQmskr9sOUlb2wECYm0lE 22YQ== X-Gm-Message-State: AHYfb5iyrL3GY7rsl+blHUrld9WEIWcwoWWzXhbYILVW8fM8Rv6IIoiz MdF+wUh8zQDaMvsa/9p40VPzLlG7smJZ X-Google-Smtp-Source: ADKCNb60d/2+m190gc1lQTk2Okq3kZSlAvgFnTjZTdEiBd5bAo5iKtIl4CdFkrhyDqvKl3Q0jsULW/85IiM0yOUSYyI= X-Received: by 10.80.207.129 with SMTP id h1mr3364299edk.120.1504010854112; Tue, 29 Aug 2017 05:47:34 -0700 (PDT) In-Reply-To: <20170829122014.GZ1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11857 Archived-At: On Tue, Aug 29, 2017 at 2:20 PM, Rich Felker wrote: >> >> 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. >> >> This has several problems: >> It prints multiple messages "invalid option -q" >> when there are options which are not in optstring. > > opterr=0; > > Either leave it 0 and always do your own error printing, or set it > nonzero just before the last call (for the current option) so that > only that one prints an error. > >> It mangles optarg if an option without argument follows >> an option with an argument. > > Maybe I'm missing what you're trying to say, but all the state is > clobbered; I don't see how optarg is a problem specifically. You can > clear or set it to a sentinel value before the relevant call if you're > trying to determine if the call set it. Across other calls (not the > one for the current option) I don't see why it matters at all what > happens to it. Yes, this can be done. It gets increasigly ugly, though. With these amounts of massaging around libc API design breakage, "getopts" builtin code in hush is almost as big as simply reimplementing getopt(): ~500 versus ~750 bytes on x86. If I factor out ash getopts implementation and use it in both shells, I can probably even decrease code size.