From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21427 invoked by alias); 15 Feb 2015 19:26:50 -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: 34549 Received: (qmail 24466 invoked from network); 15 Feb 2015 19:26:38 -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-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Ko/6AtSI c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=0HtSIViG9nkA:10 a=wY9MyXm1gOhNmXWSx70A:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <150215112622.ZM11584@torch.brasslantern.com> Date: Sun, 15 Feb 2015 11:26:22 -0800 In-reply-to: <20150214214209.6d2f5e7e@ntlworld.com> Comments: In reply to Peter Stephenson "Re: PATCH: Crash bug on garbage input (previously reported to Debian)" (Feb 14, 9:42pm) References: <150214102534.ZM4368@torch.brasslantern.com> <20150214214209.6d2f5e7e@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: PATCH: Crash bug on garbage input (previously reported to Debian) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 14, 9:42pm, Peter Stephenson wrote: } Subject: Re: PATCH: Crash bug on garbage input (previously reported to De } } On Sat, 14 Feb 2015 10:25:34 -0800 } Bart Schaefer wrote: } > Garbage input (nul bytes, etc.) can cause the newly-introduced $(...) } > parser to become confused during look-ahead and back up the input too } > far before attempting a different parse. } } Hmmm... backup characters are simply matched with input characters. } Could it be something to do with multibyte? I don't think it's multibyte, though it's possible. The sample input file that gives the error has a nested subtitution, in command position, with "${(s!...!" but no closing paren for the parameter flags, inside which is $( followed by 17 more open parens, one close paran, then a bunch of random stuff, a newline, and some more random stuff. The error occurs within cmd_or_math() when trying to ungetc the newline. (I think you were sent a copy of the file off-list.) One interesting tidbit: Even with my patch, if I "source" the test file from an interactive shell, all the garbage that comes AFTER the newline ends up on the history stack where I can pull it up with up-history. So setting errflag may be a bit too aggressive, something is failing to unwind its idea of the source of shell input. Here's a much simpler input string that triggers the same error; put this in a file and read with "source" so that the expression is ended by EOF and never has a chance to prompt for more input: ${($((()$[(s: this ends up in the history)}}) Each of ${( $(( and $[( seem to be crucial to tripping the problem, though I didn't try replacing $[ with $((. Oh, same issue right at the PS1 prompt with this: torch% ${($((()$[(s: braceparam mathsubst mathsubst> this ends up in the history)}})))} Attempt to inungetc() at start of input. zsh: Garbled input at \n (binary file as commands?) zsh: parse error near `)' If you remove the string "this ends up in the history" then nothing ends up in the history (but the error still occurs). Incidentally, the approach of calling the math parser and then falling back to subshell parsing if math fails causes some interesting double errors: torch% print $((echo ) echo ) zsh: parse error near `echo' zsh: parse error near `$((echo ) echo )'