From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1567 invoked from network); 14 Dec 2007 10:15:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Dec 2007 10:15:05 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 90007 invoked from network); 14 Dec 2007 10:15:02 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Dec 2007 10:15:02 -0000 Received: (qmail 16636 invoked by alias); 14 Dec 2007 10:14:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24248 Received: (qmail 16622 invoked from network); 14 Dec 2007 10:14:59 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Dec 2007 10:14:59 -0000 Received: from virusfilter.dotsrc.org (bifrost [127.0.0.1]) by spamfilter.dotsrc.org (Postfix) with ESMTP id 28D678058F54 for ; Fri, 14 Dec 2007 11:12:11 +0100 (CET) Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [217.69.20.190]) by bifrost.dotsrc.org (Postfix) with ESMTP for ; Fri, 14 Dec 2007 11:12:10 +0100 (CET) Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly20d.srv.mailcontrol.com (MailControl) with ESMTP id lBEAEpfl015570 for ; Fri, 14 Dec 2007 10:14:52 GMT Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 10:14:51 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.1/8.13.4) with ESMTP id lBEAEo5G001012 for ; Fri, 14 Dec 2007 10:14:50 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.14.1/8.14.1/Submit) with ESMTP id lBEAEmZt001008 for ; Fri, 14 Dec 2007 10:14:50 GMT Message-Id: <200712141014.lBEAEmZt001008@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: "Zsh Hackers' List" Subject: Re: PATCH: internal parameter flags (resend) In-reply-to: <071213204651.ZM446@torch.brasslantern.com> References: <20071213204318.2ff3e43c.p.w.stephenson@ntlworld.com> <071213204651.ZM446@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Thu, 13 Dec 2007 20:46:49 -0800." Date: Fri, 14 Dec 2007 10:14:48 +0000 From: Peter Stephenson X-OriginalArrivalTime: 14 Dec 2007 10:14:51.0107 (UTC) FILETIME=[29D77330:01C83E3A] X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.68.0.130 X-Virus-Scanned: ClamAV using ClamSMTP Bart Schaefer wrote: > I seem to recall some discussion of this in the past. If I recall > correctly, the upshot was that parameter flags affect the "display" > of a value when it finally comes to a point that's the functional > equivalent of inserting the value into a command line argument, and > that it specifically was not the intention that flags affect the > *actual* value stored in the parameter. > > The context of the discussion as I remember it was whether the flags > should be applied immediately when assigning to the parameter (or > when changing the flags of an existing parameter with typeset), vs. > being applied when the value is retrieved, and the resolution was in > favor of the latter. This means, for example, that you can change > the -R -L and -Z flags without affecting the underlying value. I vaguely remember the discussion you refer to, but it's a different issue. It is still the case that the flags can be changed without affecting the value, only when it's retrieved. You're trying to apply an additional rationale to what constitutes the value being retrieved that I don't think holds water (and I don't think was ever discussed). > Note particulars of this effect: > > schaefer<506> typeset -Z 5 -T ARY ary > schaefer<507> ARY=5 > schaefer<508> echo $ARY > 00005 > schaefer<509> echo $ary > 5 > schaefer<510> ary=(1 2) > schaefer<511> echo $ARY > 001:2 > > So far this still works with the patch, but here's the tricky bit: > > schaefer<512> echo $ARY[3] > 00002 > > With PWS's patch applied, $ARY[3] becomes "1" in this example, which > I believe is wrong. (I don't really think 00002 is correct either; > in fact I'd have said it should just be "2". Why should the padding > flags of the entire string apply to a slice of it?) I agree that the old value is wrong, but I don't see why the new value is. You're now trying to add yet another rule that the padding flags are sometimes ignored. I chanced on the problem because I was specifically expecting the new behaviour (in a simpler version, but with the new order of padding and subscripting). It is possible to compromise here, I think, by simply swapping the order of padding and subscripting in the substitution code (and actually I think the new description of the substitution code in the manual would still apply), but I haven't understood why that should be. > This is distinct from ${${ARY}[3]}, which always was "1". > > } % typeset -u param=upper > } % UPPER=VALUE > } % print ${(P)param} > } > } prints nothing, even though $param outputs UPPER, because of the way > } flags are handled in the wrong place. > > Again I think this was correct as it was. I really can't see how. I think it just creates a confusing distinction on how parameters are accessed. Why would you set the -u flag for a parameter and then expect it not to be applied? What's the point in having both flags on substitution and on parameters themselves if the latter only apply at the same time? > "upper", not "UPPER", regardless of the flags; in this case > ${(P)param} and ${(P)${param}} should be distinct, because the first > uses the value of $param as a name whereas the second treats the > substitution of $param as a name. To me that's just plain confusing. > In summary I think this change actually removes useful and intended > functionality and should be revised or backed out. I haven't seen any useful functionality in there, but certainly if there are practical examples of things that should work the old way I'd be glad to hear them. It's possible there actually are cases where you need a back door to what you originally set without altering the flags, but I can't actually think of one; all the examples I can think of would suggest you want consistency. In other words, I'm not saying there's definitely no rationale for the old way, only that I haven't seen it yet and it surprised me when I discovered how it worked. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070