From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1156 invoked from network); 10 Sep 1999 16:32:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Sep 1999 16:32:48 -0000 Received: (qmail 3658 invoked by alias); 10 Sep 1999 16:32:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7775 Received: (qmail 3651 invoked from network); 10 Sep 1999 16:32:37 -0000 From: "Bart Schaefer" Message-Id: <990910163224.ZM17291@candle.brasslantern.com> Date: Fri, 10 Sep 1999 16:32:24 +0000 In-Reply-To: <199909100921.LAA90878@hydra.ifh.de> Comments: In reply to Peter Stephenson "PATCH: 3.1.6-pws-3: more getopts bugs" (Sep 10, 11:21am) References: <199909100921.LAA90878@hydra.ifh.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: PATCH: 3.1.6-pws-3: more getopts bugs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 10, 11:21am, Peter Stephenson wrote: } Subject: PATCH: 3.1.6-pws-3: more getopts bugs } } 1. The counter for how far we are into a single option argument doesn't get } rest when OPTIND goes back to 1 (i.e. when a new function is started), only } if OPTIND is set explicitly to 0. (How can this possibly have escaped } notice for almost a decade?) It went unnoticed because it was introduced in January of 1998 when Zefram "Rewrote getopts to remove its various bugs." (Or so says ChangeLog.) It is not present in 3.0.6 (try your "badfn" test case). } 2. The manual page claims the option variable gets set to '?' even if an } error message was printed by getopts itself (i.e. no initial colon). Guess } what? To see that, remove the : and watch the second line not get } executed. This also works as expected in 3.0.6. I wonder what bugs Zefram removed? Anyway, as this works in 3.0.6 with optcind static to bin_getopts(), I wonder whether saving/restoring optcind in exec.c is in fact the right thing. The diffs in bin_getopts() from 3.0.6 to 3.1.6 are so extensive that I'm not immediately able to discern what's happening differently. It looks like maybe the 3.0 code resets optcind before returning end of options, whereas the 3.1 code sets it on entry to the function iff the user has set OPTIND=0. Restarting on OPTIND=0 must be one of the bugs Zefram fixed, but maybe he shouldn't have taken out the reset of optcind upon failure return? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com