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