From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27792 invoked by alias); 17 Oct 2017 06:42:19 -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: List-Unsubscribe: X-Seq: 41917 Received: (qmail 25920 invoked by uid 1010); 17 Oct 2017 06:42:18 -0000 X-Qmail-Scanner-Diagnostics: from aok120.rev.netart.pl by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(85.128.245.120):SA:0(-1.9/5.0):. Processed in 3.250018 secs); 17 Oct 2017 06:42:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: psprint@zdharma.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new using ClamAV (17) Date: Tue, 17 Oct 2017 08:34:08 +0200 From: Sebastian Gniazdowski To: Bart Schaefer , "=?utf-8?Q?zsh-workers=40zsh.org?=" Message-ID: In-Reply-To: <171015110946.ZM4359@torch.brasslantern.com> References: <171011100231.ZM3821@torch.brasslantern.com> <20171012165053.7cf67aa2@pwslap01u.europe.root.pri> <20171013103622.1d920b14@pwslap01u.europe.root.pri> <171013135510.ZM12458@torch.brasslantern.com> <171014185301.ZM3708@torch.brasslantern.com> <171015110946.ZM4359@torch.brasslantern.com> Subject: Re: [BUG] In reference to patch 39815, about (z) flag and $( parse error X-Mailer: Airmail (442) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 15 pa=C5=BAdziernika 2017 at 20:09:46, Bart Schaefer (schaefer=40brass= lantern.com) wrote: > This points out a different issue: > =20 > torch% setopt cshjunkiequotes > torch% printf '<%s>=5Cn' =24=7B(z)buf=7D > <=23> > <'> > torch% > =20 > Should the parse abort there=3F 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.) > =20 > 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=3F > =20 > The patch below implements that latter. I cannot fully understand, but it sounds like if it was a conservative ap= proach. I agree that parse should not abort on error and include text tha= t follows (not sure how it would resume on next =22line=22). 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. -- =20 Sebastian Gniazdowski psprint /at/ zdharma.org