From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29462 invoked from network); 14 Dec 2007 04:47:29 -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.6 required=5.0 tests=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 04:47:29 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 64269 invoked from network); 14 Dec 2007 04:47:20 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Dec 2007 04:47:20 -0000 Received: (qmail 11828 invoked by alias); 14 Dec 2007 04:47:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24245 Received: (qmail 11813 invoked from network); 14 Dec 2007 04:47:14 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Dec 2007 04:47:14 -0000 Received: from virusfilter.dotsrc.org (bifrost [127.0.0.1]) by spamfilter.dotsrc.org (Postfix) with ESMTP id BD29D8058F54 for ; Fri, 14 Dec 2007 05:44:27 +0100 (CET) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by bifrost.dotsrc.org (Postfix) with ESMTP for ; Fri, 14 Dec 2007 05:44:27 +0100 (CET) Received: from torch.brasslantern.com ([71.121.18.67]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JT000L8MVVDLOC8@vms173003.mailsrvcs.net> for zsh-workers@sunsite.dk; Thu, 13 Dec 2007 22:45:14 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id lBE4kpeT000448 for ; Thu, 13 Dec 2007 20:46:52 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id lBE4kpDL000447 for zsh-workers@sunsite.dk; Thu, 13 Dec 2007 20:46:51 -0800 Date: Thu, 13 Dec 2007 20:46:49 -0800 From: Bart Schaefer Subject: Re: PATCH: internal parameter flags (resend) In-reply-to: <20071213204318.2ff3e43c.p.w.stephenson@ntlworld.com> To: "Zsh Hackers' List" Message-id: <071213204651.ZM446@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20071213204318.2ff3e43c.p.w.stephenson@ntlworld.com> Comments: In reply to Peter Stephenson "PATCH: internal parameter flags (resend)" (Dec 13, 8:43pm) X-Virus-Scanned: ClamAV using ClamSMTP On Dec 13, 8:43pm, Peter Stephenson wrote: } } Handling of internal parameter flags, by which I means ones defined with } typeset rather than applied during the subsitution, is flaky. Hmm. 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. (However, not all flags are created equal in this respect. The -U flag of arrays, for instance, applies at assignment time.) Put another way, the parameter flags are substitution flags, not value flags, and apply only when a parameter is substituted, not every time its value is accessed. 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?) 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. The *value* of param is "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. And the pre-patch zsh does just that: torch% typeset -u param=upper torch% UPPER=VALUE torch% print ${(P)param} torch% print ${(P)${param}} VALUE In summary I think this change actually removes useful and intended functionality and should be revised or backed out. --