From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26720 invoked from network); 5 Jun 2007 14:20:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 5 Jun 2007 14:20:00 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 19370 invoked from network); 5 Jun 2007 14:19:54 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 5 Jun 2007 14:19:54 -0000 Received: (qmail 24771 invoked by alias); 5 Jun 2007 14:19:52 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23524 Received: (qmail 24762 invoked from network); 5 Jun 2007 14:19:51 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 5 Jun 2007 14:19:51 -0000 Received: (qmail 19071 invoked from network); 5 Jun 2007 14:19:51 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 5 Jun 2007 14:19:47 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly22c.srv.mailcontrol.com (MailControl) with ESMTP id l55EHaaM029693 for ; Tue, 5 Jun 2007 15:19:39 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 15:19:35 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.8/8.13.4) with ESMTP id l55EJZ2v013063 for ; Tue, 5 Jun 2007 15:19:35 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.13.8/8.13.8/Submit) with ESMTP id l55EJZSh013059 for ; Tue, 5 Jun 2007 15:19:35 +0100 Message-Id: <200706051419.l55EJZSh013059@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: "zsh workers" Subject: Re: Change in FIGNORE behavior In-reply-to: <070604095654.ZM17620@torch.brasslantern.com> References: <20a807210705291856qe306eeds250f4f9d5f4dd33f@mail.gmail.com> <200705300945.l4U9jUbE009607@news01.csr.com> <20070530112934.3950357b@news01.csr.com> <070530035810.ZM29792@torch.brasslantern.com> <200705301127.l4UBROR5010814@news01.csr.com> <20070530135436.410e11ff@news01.csr.com> <20070604104901.276f7d83@news01.csr.com> <070604095654.ZM17620@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Mon, 04 Jun 2007 09:56:54 -0700." Date: Tue, 05 Jun 2007 15:19:34 +0100 From: Peter Stephenson X-OriginalArrivalTime: 05 Jun 2007 14:19:35.0755 (UTC) FILETIME=[8B42E9B0:01C7A77C] Content-Type: text/plain MIME-Version: 1.0 X-Scanned-By: MailControl A-07-07-05 (www.mailcontrol.com) on 10.67.0.132 Bart Schaefer wrote: > } I think the ideal case would be that a failed (R) returned an index off the > } beginning of the array. > > That would be ideal for (I) as well, and in the absence of KSH_ARRAYS it > would sort of be possible. Maybe what we need is (sigh) yet another flag > that controls the behavior of index zero. > > Given such a flag (and possibly even without it), we could make it an > error to assign to array[0] (treat it as an invalid identifier) when the > KSH_ARRAYS option is not in effect. If that's possible, that would be great; I could back off the previous patch. I was figuring it's such long-standing behaviour that that won't work. However, it's not a feature you actually need, just one to stop old shells falling over. We could introduce an option KSH_INDEX_ZERO, or something. It turns out the internal changes to support that aren't trivial, because the parameter code is such a mess---it's built in a lot of layers which aren't well separated from one another and depend on little details of the layers underneath, and which furthermore are called from other parts of the shell code at all the different levels, and the resulting mess isn't documented: try to work out what the effect of changing the use of the "start" and "end" elements of a "struct value" are. I've always wanted much more hierarchical parameter code with well-defined APIs; it's looking like one of those things that are never going to happen. > When KSH_ARRAYS *is* in effect, you > already have to jump through hoops to figure out what it means for (I) > to return zero, so one is really no worse off in that case. Yes, I agree entirely with that. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview