From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24959 invoked by alias); 16 Jan 2015 18:09:46 -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: 34309 Received: (qmail 6196 invoked from network); 16 Jan 2015 18:09:42 -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 X-Originating-IP: [86.6.153.127] X-Spam: 0 X-Authority: v=2.1 cv=RcseCjdv c=1 sm=1 tr=0 a=39NrsSuza2clQiZR/7fYWQ==:117 a=39NrsSuza2clQiZR/7fYWQ==:17 a=IkcTkHD0fZMA:10 a=NLZqzBF-AAAA:8 a=q2GGsy2AAAAA:8 a=n5AgN11iPFvQ8O4V_KQA:9 a=QEXdDO2ut3YA:10 Date: Fri, 16 Jan 2015 18:04:00 +0000 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: Crash when capturing command output in completion Message-ID: <20150116180400.6be0d82e@ntlworld.com> In-Reply-To: <150116081843.ZM26927@torch.brasslantern.com> References: <150115135356.ZM23582@torch.brasslantern.com> <150115162748.ZM23670@torch.brasslantern.com> <150115204336.ZM23779@torch.brasslantern.com> <150115212036.ZM23929@torch.brasslantern.com> <20150116094436.7803b467@pwslap01u.europe.root.pri> <20150116125712.3ef52e96@pwslap01u.europe.root.pri> <150116081843.ZM26927@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 16 Jan 2015 08:18:43 -0800 Bart Schaefer wrote: > On Jan 16, 12:57pm, Peter Stephenson wrote: > } > } Only very lightly tested and so probably partial fix --- however, I'll > } commit this because (i) I'm fairly sure it's going in the right > } direction (ii) it does work in some cases and hence the shell is less > } crash-prone (iii) I get to insert a whiny message about the horrible > } interface which always improves my morale. >=20 > OK, this changed something -- I don't get a crash any more (though I > probably should as there is obviously a rogue pointer) but *without* > -DZSH_OLD_SKIPCOMM I get this: >=20 > schaefer<501> echo =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF$(ls) > Completing all expansions > =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF$(ls) > Completing original > $(ls) That's not happening here. I had no problem with inserting the output of ls in Src word by word, though there was some evidence of display funnies when it tried to insert the complete set of words as an expansion. If it still happens after rebuilding from scratch, could you see if it's related to what ls is actually outputting or some completion option? > This has to mean it's a difference between hgetc() and lex_add_raw() > or whatever; I don't really follow yet what's happening with those > new routines. The sole purpose of lex_add_raw() is to track the input buffer to be copied back raw as the contents of the $(...). Meanwhile, on top of that, it's being parsed, but that's no use to us later as we need the string for the command line argument. The complexity comes when the input tracked in this way (tokstr_raw) gets reinstalled in the normal string (tokstr) when we get to the end of the parentheses. From then on it's just a string again, until the $(...) is actually executed. pws