From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10544 invoked by alias); 7 Jun 2015 08:30:47 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35410 Received: (qmail 28692 invoked from network); 7 Jun 2015 08:30:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Date: Sun, 7 Jun 2015 10:30:42 +0200 From: Roman Neuhauser To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: getopts doesn't update OPTIND when called from function Message-ID: <20150607083042.GG15174@isis.sigpipe.cz> References: <55673FD8.7010301@inlv.org> <20150528181740.20267791@pwslap01u.europe.root.pri> <20150605064648.GE15174@isis.sigpipe.cz> <150606094641.ZM12642@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150606094641.ZM12642@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) # schaefer@brasslantern.com / 2015-06-06 09:46:41 -0700: > On Jun 5, 8:46am, Roman Neuhauser wrote: > } this diff shows how zsh (5.0.7, emulate -R sh) differs from other shells, > } and the standard IIUC: > > I believe this was previously discussed here: > > http://www.zsh.org/mla/workers//2015/msg00196.html > > The key text: > > > In zsh, if you add a SECOND call to getopts in the example function, > > you will find that the second call DOES exit with a value of 1, and > > that WHEN zsh getopts exits with a return value greater than zero, > > THEN the value of OPTIND is set as POSIX specifies. > > No one responded with an opinion of whether this conforms to the literal > specification or not. yeah, sorry. i missed that conversation. anyway, it seems perfectly unambiguous to me. the spec[*] says > Each time it is invoked, the getopts utility shall place the value of > the next option in the shell variable specified by the name operand > and the index of the next argument to be processed in the shell > variable OPTIND. *Each time* it is invoked ... shall place ... the index of *the next* argument ... in ... OPTIND. in zsh, OPTIND has the index of the last processed option instead, until "the end of options is encountered". so that's one clear violation of the spec. > When the end of options is encountered, the getopts utility shall exit > with a return value greater than zero; the shell variable OPTIND shall > be set to the index of the first operand, or the value "$#" +1 if > there are no operands; the name variable shall be set to the > character. When the end of options is encountered ... the name variable shall be set to the character. in zsh, the name parameter has the value of the last processed option instead. that's another clear violation. [*] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html -- roman