From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9476 invoked from network); 16 Jan 2009 04:19:57 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) 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.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 16 Jan 2009 04:19:57 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 96350 invoked from network); 16 Jan 2009 04:19:48 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 16 Jan 2009 04:19:48 -0000 Received: (qmail 10327 invoked by alias); 16 Jan 2009 04:19:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26319 Received: (qmail 10313 invoked from network); 16 Jan 2009 04:19:43 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 16 Jan 2009 04:19:43 -0000 Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by bifrost.dotsrc.org (Postfix) with ESMTP id 6C5EF80271F0 for ; Fri, 16 Jan 2009 05:19:37 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KDJ002SSQOA25H1@vms042.mailsrvcs.net> for zsh-workers@sunsite.dk; Thu, 15 Jan 2009 22:19:28 -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 n0G4JDVC020277 for ; Thu, 15 Jan 2009 20:19:13 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n0G4JCwl020276 for zsh-workers@sunsite.dk; Thu, 15 Jan 2009 20:19:12 -0800 Date: Thu, 15 Jan 2009 20:19:12 -0800 From: Bart Schaefer Subject: Re: treatment of empty strings - why is this not a bug? In-reply-to: <18796.17298.94642.461735@gargle.gargle.HOWL> To: Zsh list Message-id: <090115201912.ZM20275@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <18796.17298.94642.461735@gargle.gargle.HOWL> Comments: In reply to Greg Klanderman "treatment of empty strings - why is this not a bug?" (Jan 13, 2:32am) X-Virus-Scanned: ClamAV 0.92.1/8870/Thu Jan 15 21:57:00 2009 on bifrost X-Virus-Status: Clean I was hoping to just let this thread go by, but maybe I'm the only one still on list who's been around long enough to have an inkling of what is going on here. On Jan 13, 2:32am, Greg Klanderman wrote: } } I just don't understand why there should be any distinction } between the splitting and dropping of empty strings. It all goes back to the semantics of $@. Here's bash: $ set -- aa "" bb "" cc $ echo $# 5 $ for x in $@; do echo $x; done aa bb cc $ Note that the empty elements of $@ are dropped. Now, you might argue that the *reason* they're dropped is because $@ has been joined into a string and then re-split into words on $IFS, but the end result is that empty elements disappear unless quoted. Paul Falstad (original author of zsh) made a conscious decision that a non-empty string, even one containing some or only characters that appear in $IFS, was a significant item of data and should remain in the expansion of $@. However, he was unwilling to deviate from the standard semantics of $@ to the point of treating empty strings as significant. Too many programs that deal with file names, for example, would begin spewing errors if they received empty strings in their argument lists when called as e.g. ls -l $@. The point is to be minimally surprising to the person who just doesn't want to think very hard about array and $IFS semantics, not to be entirely logically consistent to someone who analyzes the behavior in detail. If you're enough of a geek to care, you're also enough of a geek to figure out a workaround. Everything else follows from there. $a[@] is supposed to have the same semantics as $@ for any array a; this must be, so that $argv[@] is exactly equivalent to $@. As to why things behave seemingly differently when using (s-:-) or the like, well, in many cases zsh's parameter expansion was developed looking only at the end results and not by paying close attention to which "layer" of the implementation performed which operation. As new features were built on top of the implementation, particularly some of the nested expansion tricks, unexpected oddities arose because that layering became more important. Some of those oddities became widely enough relied on in scripts that we're now essentially stuck with them. (Zsh is not one of "those" open source projects that is willing to allow every new release to be "improved" by breaking everything that went before. For the most part, what has always worked still works, and if it doesn't it's usually because it was never intended to work, not because someone decided that the way it was once meant to work is now philosophically wrong.) The more literal explantion for your example has to do with multiple consective separators being treated as a single word break (as happens with, for example, multiple consecutive spaces when splitting on $IFS in the shwordsplit case) vs. multiple separators being treated as multiple word breaks. However, I've forgotten whether rcexpandparam was intentionally or accidentally given that side-effect.