From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3149 invoked by alias); 2 Jul 2012 09:45:43 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30558 Received: (qmail 2375 invoked from network); 2 Jul 2012 09:45:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 2 Jul 2012 10:11:08 +0100 From: Peter Stephenson To: Subject: Re: PATCH Re: let unset array element remove compatible with bash Message-ID: <20120702101108.7c07b233@pwslap01u.europe.root.pri> In-Reply-To: <120701152310.ZM28640@torch.brasslantern.com> References: <120221210106.ZM13374@torch.brasslantern.com> <20120222095248.1ea8140b@pwslap01u.europe.root.pri> <120222092827.ZM24425@torch.brasslantern.com> <20120222201939.53899980@pws-pc.ntlworld.com> <120701095354.ZM28458@torch.brasslantern.com> <20120701191526.50e2cf7d@pws-pc.ntlworld.com> <120701152310.ZM28640@torch.brasslantern.com> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.101.10.18] X-Scanned-By: MailControl 7.7.2 (www.mailcontrol.com) on 10.71.0.138 On Sun, 1 Jul 2012 15:23:10 -0700 Bart Schaefer wrote: > On Jul 1, 7:15pm, Peter Stephenson wrote: > } Subject: Re: PATCH Re: let unset array element remove compatible with bash > } > } On Sun, 01 Jul 2012 09:53:54 -0700 > } Bart Schaefer wrote: > } > So the patch below makes > } > > } > noglob unset foo[x] > } > > } > work properly. If x is an existing index (or valid slice), it is cut > } > from the array as if by foo[x]=(). > } > } Do you mean that? That's not how bash works, it doesn't cut the > } element, just remove the value at that index > > I do mean that; this is the closest zsh can get to the bash behavior, I > think. Bash represents arrays as linked lists of position-value pairs, > so it's possible for it to have an array with a hole, but zsh uses real > arrays. > > It'd be easy enough to tweak the patch to put an empty string into the > element instead of splicing the array, but then it'd be inconsistent with > bash's expansions of ${foo[@]}, ${#foo[@]}, etc. Hmm... I'd have said putting in an empty element in was the least surprising thing to do, at least in the short term. I don't think shifting an array so that the numbering is different mimics the ability to have only certain elements set to any great degree, there are too many other cases. If we ever did add the ability, the effect would be to remove elements that currently appear as empty strings --- so having the array index shifted would then look wrong. It's a bit hard to give a definitive answer because, with the current underlying behaviour, neither meaning of unsetting an array element actually adds the ability to do something you can't already do. -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog