From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10865 invoked by alias); 20 Feb 2012 11:01:17 -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: 30236 Received: (qmail 17432 invoked from network); 20 Feb 2012 11:01:11 -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, 20 Feb 2012 10:59:01 +0000 From: Peter Stephenson To: Subject: Re: Bug with bash emulation regarding ':' Message-ID: <20120220105901.51cbbd22@pwslap01u.europe.root.pri> In-Reply-To: <120219154515.ZM7225@torch.brasslantern.com> References: <20120129183644.6d49d237@pws-pc.ntlworld.com> <120131202909.ZM6076@torch.brasslantern.com> <120201082929.ZM7032@torch.brasslantern.com> <20120205201133.3bcd2b7f@pws-pc.ntlworld.com> <20120214174154.36268595@pwslap01u.europe.root.pri> <4F3AEE8D.9050705@case.edu> <20120215123641.01e5a4fd@pwslap01u.europe.root.pri> <120219154515.ZM7225@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.170] X-Scanned-By: MailControl 7.6.6 (www.mailcontrol.com) on 10.68.0.136 On Sun, 19 Feb 2012 15:45:15 -0800 Bart Schaefer wrote: > Hence it appears "we rely on the nested substitution to do the splitting > we see in the top-level parameter expansion" is incorrect, at least in > this instance? That's good. Maybe we're only relying on it to get the assigned value, after all, so the splitting is done in the same order as bash (just hitherto with different options applied at each stage). > In fact it may be that PREFORK_SINGLE is the only thing needed there, > and PREFORK_NOSHWORDSPLIT is extraneous? The basic behaviour is certainly given with PREFORK_SINGLE only (spbreak initialisation around line 1540); there's one oddity where we'll use SHWORDSPLIT on its own to determine the default for (@) behaviour if not forced on around line 1652. That's rather confusing and my previous change may already have had some impact on this, since we've reduced the number of cases where SHWORDSPLIT is forced on. > Although all tests still pass (except the new one introduced by 30203 > which must be tweaked), I should note the above changes the "native" > zsh behavior as well. I woudn't imagine this is going to cause much > trouble -- I found no uses of ${...=...} in the default $fpath, which > includes the whole completion suite, etc. -- but it does mean we might > want to make it conditional upon something. For example: > + spbreak ? PREFORK_SINGLE : PREFORK_NOSHWORDSPLIT, I suppose that's as good as anything. Goodness knows how to document this. I'm not sure I really understand how the ramifications of one option cause so much divergence internally, but as far as I can see (and I can't, really) that should cover the two obvious cases where SHWORDSPLIT is or is not on at the top level. Whether it covers explicit splitting in nested substitutions or (@) processing is another matter. However, given we don't tend to rely on ${...=...}, and the shenanigans with parameter flags don't apply to POSIX, it doesn't seem worth doing any more research, so I think this is probably as good as we need. Thanks. It might be worth folding this in and making 4.3.17 immediately, there's no real point in releasing only a partial fix. -- 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