Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH 2/2] clear the heredoc list in case par_event() fails
- X-seq: zsh-workers 43854
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- Subject: Re: [PATCH 2/2] clear the heredoc list in case par_event() fails
- Date: Thu, 29 Nov 2018 10:39:15 -0800
- Cc: "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t7e2jDH24K4qx7pnC1D4ZTn+sNakvE9D/M+x13yoOZA=; b=RQNUk+KZNPZaUxPqB584qtQsjLjQjrEaFJj2xtt6SZqRe3Zvnmlg1+fz0nBDfhVnjZ 3OPtCFBwbIDVckn/JYPaPjWdGSG7mgXM8DycMm6bK9pQomJ64tXX/P5LSGwn+2+kSuPt MbEF8e9dluMqUtgVyo5DDq4REnDhdwotG5NlmmjDARmZed64upqr+FvxwuMlnTA+lAa1 7xfg3CcBIlr6VZW3zK8hl+3a9Llax6Hq403fFgFaLMlA9i0ge5IfGc50ZQHUKJTZhMt9 zKvh/q+O0XfKe7x87znCsSrhXtwNTSgn5cHLRirP/Q5YkZ+3JoNNyEvHNJURIT1KFjPc f+Kw==
- In-reply-to: <1543512844.6025.28.camel@samsung.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <1429277155-24607-1-git-send-email-kdudka@redhat.com> <1429277155-24607-2-git-send-email-kdudka@redhat.com> <20150417201753.41812294@ntlworld.com> <CGME20181129163223epcas2p409f7d3c4b9417e2a3a9956abfd64ea3b@epcas2p4.samsung.com> <2172016.U8TV6t29ou@kdudka-nb> <1543512844.6025.28.camel@samsung.com>
On Thu, Nov 29, 2018 at 9:42 AM Peter Stephenson
<p.stephenson@xxxxxxxxxxx> wrote:
>
> There's some slightly icky linkage between lex errors and the top level
> requiring tok to be LEXERR. The simple fix using the existing
> signalling looks like the following. I definitely don't think the tok =
> LEXERR has a moral right to percolate through in the way it must
> previously have been doing to avoid this, and the lexer does certainly
> have the right to update the token when signalling a parse error, so
> (famous last words) it's hard to see what could be wrong with this...
Might this need to be conditional upon ... something ... so that e.g.
${(z)...} on a malformed here-document doesn't throw an error? I
don't have the code handy to poke around.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author