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

Re: [BUG] In reference to patch 39815, about (z) flag and $( parse error

On 15 października 2017 at 20:09:46, Bart Schaefer (schaefer@xxxxxxxxxxxxxxxx) wrote:
> This points out a different issue:
> torch% setopt cshjunkiequotes
> torch% printf '<%s>\n' ${(z)buf}
> <#>
> <'>
> torch%
> Should the parse abort there? Other parse errors don't cause (z) to
> fail when cshjunkiequotes is not set. (At least it should not abort
> silently, but (z) suppresses parse error messages.)
> If the parse should not abort, should it act as if cshjunkiequotes
> were not set, or should it treat the line from the quote to the end
> as a STRING token and then resume parsing on the next line?
> The patch below implements that latter.

I cannot fully understand, but it sounds like if it was a conservative approach. I agree that parse should not abort on error and include text that follows (not sure how it would resume on next "line"). Hmm but now I think I understand. cshjunkiequotes doesn't allow newlines in strings, so indeed it is a valid point that on error it should consume to end of *line*, not end of parsed *buffor*.

I've run the unit tests and the latest patch didn't influence them.

Sebastian Gniazdowski
psprint /at/ zdharma.org

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