From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22731 invoked by alias); 12 Oct 2017 15:58:18 -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: X-Seq: 41870 Received: (qmail 26663 invoked by uid 1010); 12 Oct 2017 15:58:18 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.w1.samsung.com 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(210.118.77.12):SA:0(-6.9/5.0):. Processed in 1.817152 secs); 12 Oct 2017 15:58: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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-AuditID: cbfec7ef-f79ee6d000003120-08-59df8f61e15a Date: Thu, 12 Oct 2017 16:50:53 +0100 From: Peter Stephenson To: "zsh-workers@zsh.org" Subject: Re: [BUG] In reference to patch 39815, about (z) flag and $( parse error Message-id: <20171012165053.7cf67aa2@pwslap01u.europe.root.pri> In-reply-to: Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsWy7djPc7qJ/fcjDX4eMrM42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGYunPWIt2MBZsfLUK/YGxr3sXYycHBICJhLvZk5ghLDFJC7c W8/WxcjFISSwjFHi8LcTjBBOL5NE5/TlTDAd/6deZ4WrevbxHTNIQkhgGpPEpzmxEIlNjBI3 vx+FmnWWUeLf32awJSwCqhKn7p4HW84mYCgxddNssLiIgL7ExT+3wGxhgWCJNTu3g63jFbCX aLp0mw3E5gSKz92/DmwbP1D91b+foE6yl5h55QwjRL2gxI/J91hAbGYBHYlt2x6zQ9jyEpvX vGUGOUhCYA6bxKS3j6CaXSTe/r0CDQ1hiVfHt0DZMhKXJ3ezQNj9jBJPun0hmmcwSpw+s4MN ImEt0Xf7IiPEBj6JSdumA23gAIrzSnS0CUGUeEhc+7kOao6jxMTp95kgobKbWWLXmw/sExgV ZiE5fBaSw2chOXwBI/MqRpHU0uLc9NRiQ73ixNzi0rx0veT83E2MwGRw+t/x9zsYnzaHHGIU 4GBU4uEVqLofKcSaWFZcmXuIUYKDWUmE16MTKMSbklhZlVqUH19UmpNafIhRmoNFSZzXNqot UkggPbEkNTs1tSC1CCbLxMEp1cA4q/X7vgfyWruap77krXWelHJ3rr4NU3lrR/qH8hgdS13p Dq+jJ26WyHlYXVh9q4D9id/ZNTeFCx/1yLGypB1u+cZySW5GWfB6qerV7GEZW9nPHbr536zM tnXmgWmGO8zfhbSe8Tkyd7s5v0L34+8f0ww7mcL8v18KYjKots5tnbfbZ+aHBexKLMUZiYZa zEXFiQBQ7OT/AgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsVy+t/xy7qJ/fcjDVbMlbM42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGYunPWIt2MBZsfLUK/YGxr3sXYycHBICJhL/p15nhbDFJC7c W8/WxcjFISSwhFHi6q4WRpCEkMAMJokbV3ghEpsYJQ4/38gKkTjLKPH8TR2IzSKgKnHq7nmw qWwChhJTN80GaxYR0Je4+OcWmC0sECyx9skksBpeAXuJpku3gbZxcHACxS88TIaYv5tZYsW6 LWA1/EC9V/9+YoK4zl5i5pUzjBC9ghI/Jt9jAbGZBbQkNm9rYoWw5SU2r3nLDHGbusSNu7vZ JzAKz0LSMgtJyywkLQsYmVcxiqSWFuem5xYb6RUn5haX5qXrJefnbmIEhvK2Yz+37GDsehd8 iFGAg1GJh1eg6n6kEGtiWXFl7iFGCQ5mJRFej06gEG9KYmVValF+fFFpTmrxIUZpDhYlcd7e PasjhQTSE0tSs1NTC1KLYLJMHJxSDYxXWfoVHn9YbXy6nl3mmJMgb0V0S90rPbE5F2ccOdRz nkv1C/uJzHb1nBSXFQWppw/nitpvrWAteMYz6eMVF9HFpy2ifuc25nzbsmzBnIfpNXPlPs1X sf9ZuVlrGudZpZPpxwTyHvgY/BaqdNkT9rdrtf5Pidu/XwnyhXD6eObZzppaLcZUelKJpTgj 0VCLuag4EQDo0lXYYQIAAA== X-CMS-MailID: 20171012155057eucas1p2dce65a3af99cddefe0f182f7e5c6e90a X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-CMS-RootMailID: 20171012152721epcas4p2fe3c8f1f97989825241b11e5a83fed75 X-RootMTR: 20171012152721epcas4p2fe3c8f1f97989825241b11e5a83fed75 References: <171011100231.ZM3821@torch.brasslantern.com> On Thu, 12 Oct 2017 08:26:35 -0700 Bart Schaefer wrote: > It'd most likely need to be in bufferwords(), which somehow needs to > know that the STRING token returned from the lexer is [or not] a > comment and that therefore it should [or not] ignore the subsequent > NEWLIN. However, that cascades all the way down into gettok() which > is where the "#" character is recognized and everything from there up > to but not including the newline is consumed. The traditional fix for this is a hacky state variable. We'd incremented it (or set it to 1?) on the comment character, and decrement it (or set it to 0?) at the newline. But, if I'm following, either we might need to decrement it after the newline has been processed, or tweak bufferwords() to add an extra state for detecting the newline when it knows it's in that state, which implies an extra stage of the dance. It's not very elegant but there is lots of prior art in terms of signalling between gettok() and the parser. > (PWS, it would be helpful if you could include workers article numbers > in your commit logs.) Most of them do, except the ones anyone actually looks at. pws