From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29798 invoked from network); 18 Mar 2008 12:14:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Mar 2008 12:14:18 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 29500 invoked from network); 18 Mar 2008 12:14:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Mar 2008 12:14:10 -0000 Received: (qmail 138 invoked by alias); 18 Mar 2008 12:14:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24723 Received: (qmail 120 invoked from network); 18 Mar 2008 12:14:07 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Mar 2008 12:14:07 -0000 Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by bifrost.dotsrc.org (Postfix) with ESMTP id B26B380EC9D1 for ; Tue, 18 Mar 2008 13:13:58 +0100 (CET) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080318121625.RKWW16169.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Tue, 18 Mar 2008 12:16:25 +0000 Received: from pws-pc.ntlworld.com ([81.107.42.63]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20080318121547.KHJF17393.aamtaout02-winn.ispmail.ntl.com@pws-pc.ntlworld.com> for ; Tue, 18 Mar 2008 12:15:47 +0000 Received: from pws-pc (pws-pc [127.0.0.1]) by pws-pc.ntlworld.com (8.14.2/8.14.2) with ESMTP id m2ICDULc004081 for ; Tue, 18 Mar 2008 12:13:30 GMT Message-Id: <200803181213.m2ICDULc004081@pws-pc.ntlworld.com> From: Peter Stephenson To: Zsh hackers list Subject: Re: ${a[(i)pattern]} if a=() In-Reply-To: Message from Bart Schaefer of "Sun, 16 Mar 2008 17:59:46 MST." <080316175946.ZM10427@torch.brasslantern.com> Date: Tue, 18 Mar 2008 12:13:30 +0000 X-Virus-Scanned: ClamAV 0.91.2/6288/Tue Mar 18 11:43:22 2008 on bifrost X-Virus-Status: Clean Bart Schaefer wrote: > On Mar 16, 11:23pm, Stephane Chazelas wrote: > } > } > I think it's supposed to return 0 because it didn't match. 1 indicates > } > it matched the first array element. > } [...] > } > } According to the manual: > } > } matching key found is the result. On failure substitutes one more > } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > } than the last currently valid index, as discussed under the > } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > } description of `r'. > } ^^^^^^^^^^^^^^^^^^^ > The reason we're getting into trouble here is because there is *no* valid > index when the array is empty. 0 is no longer a "currently valid index", > so to return "one more than the last" is in some sense also invalid, and > zero is the only index that is always invalid (barring KSH_* behavior). > > My personal opinion is that Stephane has the right of it here, and this > empty-array case is just one that we missed way back when we added the > "missing (i) falls of the top end" behavior. I've read through the manual again, and you're right, the sense of it is it should be one, because it's "off the end". As Stephane pointed out, zero looks screwy here (whatever the arguments about validity of indices). So you should commit the patch. The one that should definitely return zero is (I), but it does. This is where the ambiguity was in the past, since there was no "off the beginning". -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/