From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4673 invoked by alias); 20 Mar 2015 10:57:40 -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: 34752 Received: (qmail 12955 invoked from network); 20 Mar 2015 10:57:28 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f5-b7fc86d0000066b7-4e-550bfc6ca786 Date: Fri, 20 Mar 2015 10:57:03 +0000 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: capturing output of !! not working Message-id: <20150320105703.2754b6af@pwslap01u.europe.root.pri> In-reply-to: <20150319125351.1e270c2d@pwslap01u.europe.root.pri> References: <20150319105716.620cd931@pwslap01u.europe.root.pri> <20150319125351.1e270c2d@pwslap01u.europe.root.pri> Organization: Samsung Cambridge Solution Centre 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-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsVy+t/xq7o5f7hDDSas17c42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGaevWhW8EKhYcfAucwNjH28XIyeHhICJxM5165kgbDGJC/fW s4HYQgJLGSUaZrl3MXIB2UuYJLb3/WSFcLYxSmzqPM0CUsUioCrxcMp2ZhCbTcBQYuqm2Yxd jBwcIgLaEu0fxUDCwgL6EldmdTCBhHkF7CWuHATbxSngIHHsxH1GiJGtTBJT+jaygiT4geqv /v0EdZC9xMwrZxhBbF4BQYkfk++BrWUW0JLYvK2JFcKWl9i85i0zxNHqEjfu7mafwCg0C0nL LCQts5C0LGBkXsUomlqaXFCclJ5rpFecmFtcmpeul5yfu4kRErBfdzAuPWZ1iFGAg1GJh/fE ce5QIdbEsuLK3EOMEhzMSiK8L94DhXhTEiurUovy44tKc1KLDzEycXBKNTAeCzrEb7xiy5KV E5/ovamev6Qk6tXT7Yu/GoRMc65e91VlruSLkyYs6n/atWd+skh0ZlP/OsFx2QtbVpVrXW5c 2yO+3+78bS6x2vvSjitGf634bYpUeoV8hRYUKlcsjOt2uZbzdTs/8wy/5qzNK7U1z9y7eTXv UmDwncWh3Wwy8xgvPr7h6FamxFKckWioxVxUnAgAeLmZ7jYCAAA= On Thu, 19 Mar 2015 12:53:51 +0000 Peter Stephenson wrote: > On Thu, 19 Mar 2015 08:27:56 -0400 > Vin Shelton wrote: > > The !! command now appears inside the $(), > > but the output is not captured: > > This will be an effect of the history substitution turning up in the > wrong place (hence you're seeing it on stdout which you shouldn't) owing > to the interaction with the nested parsing. Not quite --- it's another similar problem to the last, that history and alias expansions are pushed onto the input stack in a similar way but need different processing. The new code is actually slightly more efficient; inungetc() did too much work for the case in question. The comment I've added is a distinct oversimplification, but I don't want to write an essay. I think what I'm seeing here is another symptom of the general entanglement between input levels (that's been there since the start) that's also been giving Bart headaches. You *should* see the expansion on stdout, that's completely standard. Because I always use HIST_VERIFY I'd forgotten. It shouldn't be rocket science to simplify the zpty-based stuff to the point where we have a framework for testing history. However, the baseline for what counts as rocket science is a little bit different in these parts. pws diff --git a/Src/input.c b/Src/input.c index 92b1ad1..30970a0 100644 --- a/Src/input.c +++ b/Src/input.c @@ -571,8 +571,20 @@ inpoptop(void) { if (!lexstop) { inbufflags &= ~INP_ALCONT; - while (inbufptr > inbuf) - inungetc(inbufptr[-1]); + while (inbufptr > inbuf) { + inbufptr--; + inbufct++; + inbufleft++; + /* + * As elsewhere in input and history mechanisms: + * unwinding aliases and unwinding history have different + * implications as aliases are after the lexer while + * history is before, but they're both pushed onto + * the input stack. + */ + if ((inbufflags & (INP_ALIAS|INP_HIST)) == INP_ALIAS) + zshlex_raw_back(); + } } if (inbuf && (inbufflags & INP_FREE))