Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: Crash bug on garbage input (previously reported to Debian)

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 <schaefer@xxxxxxxxxxxxxxxx> 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:

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 )'

Messages sorted by: Reverse Date, Date, Thread, Author