From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25841 invoked by alias); 31 Jul 2014 16:52: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: X-Seq: 32926 Received: (qmail 14304 invoked from network); 31 Jul 2014 16:52:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f156d0000063c7-bc-53da71e1e858 Date: Thu, 31 Jul 2014 17:42:08 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: $(...) and << Message-id: <20140731174208.67f1b392@pwslap01u.europe.root.pri> In-reply-to: <140731092023.ZM16680@torch.brasslantern.com> References: <20140731092711.GA28401@chaz.gmail.com> <140731092023.ZM16680@torch.brasslantern.com> 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+NgFupmluLIzCtJLcpLzFFi42I5/e/4Vd2HhbeCDf7s1LE42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGd0nfjEWnBetePjRpIGxQbCLkYNDQsBE4swMlS5GTiBTTOLC vfVsXYxcHEICSxkl/v/tg3KWM0lcPDeDFaSKRUBVomPyZTCbTcBQYuqm2YwgtoiAuMTZtedZ QGxhASmJYw8Ws4HYvAL2Etd+fGcHsTkFrCTalj9hBrGFBJIl2ha+BuvlF9CXuPr3ExPEFfYS M6+cYYToFZT4Mfke2ExmAS2JzduaWCFseYnNa94yT2AUmIWkbBaSsllIyhYwMq9iFE0tTS4o TkrPNdQrTswtLs1L10vOz93ECAnALzsYFx+zOsQowMGoxMMbcfNKsBBrYllxZe4hRgkOZiUR 3rfht4KFeFMSK6tSi/Lji0pzUosPMTJxcEo1MGqWfrjoeelNodTpmu0CkXd6twi5dnxiDg7j nD+hX5G7qKP3kMOkFPP/X35fPruw6vLTnUe26928bJqlXFKjc9p1why7EzMqdRz3+oe7Lbnf sD/ef8U264R0mTCekMN9027J+rRkLpK4wswo+sQ8a21//tbJ66LdTt7Pljk/c5ZRYUdUYoKs qhJLcUaioRZzUXEiANm53/geAgAA On Thu, 31 Jul 2014 09:20:23 -0700 Bart Schaefer wrote: > On Jul 31, 10:27am, Stephane Chazelas wrote: > } > } $ zsh -c 'echo $(cat << EOF > } blah) > } EOF > } ); echo test' > } zsh:4: parse error near `)' > > Yeah, to fix that we're going to have a write a whole new chunk of parser > (lexer, really) specifically for $(...). There's an entry point for it > now, but all it does is try to lexically consume a string ending with ")"; > it handles balanced paren pairs but not the situation above. I'm wondering if it's not *quite* that hard, but still far from minor... one of those things that could really, really, really do with someone with newly kindled enthusiasm taking an active interest in... - Check if it looks like $( ... ) or $(( ... ) ... ) but not $(( ... )) as before, in other words we have to guess if it's $( ... ) by looking for a stray ")" that might actually not be the end of the command substitution but probably implies it's not a $(( ... )) substitution. A bit icky but we've done worse. - Re-enter the parser at this point within the lexer and keep going until we encounter an unexpected token, and if it's ")" everything's OK. This is not substantially different from parsing the $(...) contents as now, just much earlier, so it might not be such a lot of work. - Now it gets interesting. (Unless I'm missing something.) We've just parsed something that as far as the top-level (or rather next-level-up) parser is concerned is just a string that's part of an argument. Either we've got to store that in a special way to say "retrieve this pre-parsed stuff as part of this string when you need to substitute it", or we simply record what we parsed and store it as a string for later reparsing. We'd almost certainly get away with the latter --- it may be the text is present in the current history line, since we can't rely on going back and getting from the input once that's been parsed, though I'm not sure that's always maintained in every circumstance. > } By the way, is there any plan of having an issue tracker for > } zsh somewhere. That would help to keep track of the known > } issues. > > An issue tracker needs to be part of a larger plan -- we tried using the > tracker at SourceForge but it didn't work because no one monitors it, so > it became an issue black hole. At the moment there isn't anyone to take > that responsibility. Yes, exactly. A full issue tracker allowing public input is a lot of maintenance work. In principle it would be less work just to have an internal list of issues that's basically the result of discussion on this list and can be published as such. But it's still some work for someone. pws