From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 950 invoked by alias); 13 Jan 2015 20:39:18 -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: 34270 Received: (qmail 23140 invoked from network); 13 Jan 2015 20:39:04 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7/qeQvNMhEgg98CdDc2VQzgrXVA6OsAsUfaQIURahGM=; b=n/JIQ7BWNhiFRIzUD8GjmUlbEXku3rY2X4AdInW9S2i04iqVe2O26h50nFnFJSHosc 5BRnmdtOG9Zc0WSj/Pm6630hiIca8E1FycD3I09wD+aeGMMEoR0khm7uBg5evWzu6pjh oclXWLbnGPpz04wwnBd04pNvSeJsme5o1D1ughPYDhJtzqr7gsGE2K8kGmYeG2zAUUKy K4c7Knqa4T0XwzgMLFLJkB0L9hSKUFYvYean4du9KJlBTB5uRpWtDm4kgnld0XK/tNFY X4WhhcaKIkUNw6gMi47+bOGnlx/nuW16rSu9VAoYu5c4ZSOHdghubPbFte5iFMQ3/EVc XQuw== MIME-Version: 1.0 X-Received: by 10.42.39.6 with SMTP id f6mr1420158ice.14.1421181539236; Tue, 13 Jan 2015 12:38:59 -0800 (PST) Date: Tue, 13 Jan 2015 13:38:59 -0700 Message-ID: Subject: OPTIND set incorrectly by getopts for options without arg From: Simon Chiang To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary=90e6ba61493ccec17e050c8e9c8f --90e6ba61493ccec17e050c8e9c8f Content-Type: text/plain; charset=UTF-8 Back in 2007 there was a question posted to the mailing list regarding OPTIND and getopts (http://www.zsh.org/mla/users/2007/msg01188.html). To quote, with some notes and one modifcation: With zsh 4.3.4 the OPTIND incremental bebavior is inconsistent for options with argument and without argument. For option with argument, OPTIND points to next argument, while for option without argument it points to current argument. func() { OPTIND=1 # reset OPTIND each time in to prevent carryover getopts a:b optvar shift $(( OPTIND -1 )) echo "$OPTIND, $1" } func -a x y z output: 3, y # this is the correct output func -b x y z output: 1, -b # this is the questionable output Is this a bug? There is no consistent way to do "shift" as such. Turns out according to the POSIX spec this is a bug ( http://pubs.opengroup.org/onlinepubs/000095399/utilities/getopts.html) 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 non-option-argument.... Any of the following shall identify the end of options: the special option "--", finding an argument that does not begin with a '-', or encountering an error. Unless I'm misreading that means that in the first example "y" indicates the end of options so the correct output is "3, y". In the second example the "x" indicates the end of options so the correct output is "2, x". For what it's worth bash and dash set OPTIND in this way. The original email was regarding zsh 4.3.4. I can confirm this is still the behavior at zsh 4.3.9. Simon --90e6ba61493ccec17e050c8e9c8f--