From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28606 invoked by alias); 19 Feb 2012 23:45:32 -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: 30233 Received: (qmail 15470 invoked from network); 19 Feb 2012 23:45:30 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120219154515.ZM7225@torch.brasslantern.com> Date: Sun, 19 Feb 2012 15:45:15 -0800 In-reply-to: <20120215123641.01e5a4fd@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Bug with bash emulation regarding ':'" (Feb 15, 12:36pm) 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> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Subject: Re: Bug with bash emulation regarding ':' Cc: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 15, 12:36pm, Peter Stephenson wrote: } } To get this behaviour in zsh we'd have to do the assignment earlier } than we currently do. The assignments around line 2705 of subst.c would } need to buried inside multsub() in such a way that any splitting owing to } the top-level settings happened later --- which is very difficult since } we rely on the nested substitution to do the splitting we see in the } top-level parameter expansion because it parses it so knows how to split } it. Whether there are remaining gotchas owing to ordering I don't know. I've been puzzling over this on and off for the last few days and it just doesn't seem as though it ought to be that hard. There are some comments in subst.c like this one: * This is where we extract a value (we know now we have * one) into the local parameters for a scalar (val) or * array (aval) value. TODO: move val and aval into * a structure with a discriminator. Hope we can make * more things array values at this point and dearrayify later. * v->isarr tells us whether the stuff from down below looks * like an array. So at first I was thinking that it might be time to do that, so multsub could for example return both the split and not-split expansions of the right-side of the assignment and the caller would then use one for the assignment and the other for the inline expansion. But then I traced the call and discovered that the newlines have already been removed and rejoined as spaces before multsub even returns; the call that handles this branch doesn't even pass down the aval parameter. 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? Consequently I tried this: --- ../zsh-forge/current/Src/subst.c 2012-02-12 13:31:49.000000000 -0800 +++ Src/subst.c 2012-02-19 15:19:49.000000000 -0800 @@ -2693,7 +2693,7 @@ *idend = '\0'; val = dupstring(s); if (spsep || !arrasg) { - multsub(&val, PREFORK_NOSHWORDSPLIT, NULL, &isarr, NULL); + multsub(&val, PREFORK_SINGLE|PREFORK_NOSHWORDSPLIT, NULL, &isarr, NULL); } else { if (spbreak) split_flags = PREFORK_SPLIT|PREFORK_SHWORDSPLIT; This faithfully reproduces the bash behavior in several tests I tried. In fact it may be that PREFORK_SINGLE is the only thing needed there, and PREFORK_NOSHWORDSPLIT is extraneous? (Aside: My first thought was to use PREFORK_ASSIGN, but that's only used in filesub. A more thorough approach might be to teach multsub about assignment context.) Have I missed something important? (Chet Cc'd just for interest, he can probably be dropped from further discussion on this topic.)