Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: Error parsing $(...)
- X-seq: zsh-workers 26659
- From: Peter Stephenson <pws@xxxxxxx>
- Subject: Re: PATCH: Error parsing $(...)
- Date: Mon, 2 Mar 2009 10:06:41 +0000
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <090227083334.ZM24342@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: CSR
- References: <20090226094507.43cf3c16@xxxxxxxxx> <20090226225743.1b707d46@pws-pc> <20090227101941.5552f177@pws-pc> <090227083334.ZM24342@xxxxxxxxxxxxxxxxxxxxxx>
On Fri, 27 Feb 2009 08:33:34 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> This doesn't work properly with respect to NO_INTERACTIVECOMMENTS:
>
> schaefer<501> print $(echo XX
> echo this # is not a comment
> echo YY)
> XX this YY
> schaefer<502> allopt interactive
> interactive on
> interactivecomments off
That behaviour hasn't changed, it's always worked that way. The bug was
only that stuff after the '#' wasn't properly ignored.
It's never been well defined whether the text of a "$(...)" was
"interactive" in the sense meant. The bit that happens interactively is
reading from "$(" until ")" is hit, during which the lexical analsyer isn't
looking for comments because it know the "end of the current interactive
line" (again, in some not very well defined sense) is after the ")". After
that the string is stored internally and evaluated later. Anyway, it's
probably too late to do it the other way now, but if someone wants to write
a patch to clarify it they're welcome.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author