From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18251 invoked by alias); 19 Feb 2015 21:47:20 -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: 34576 Received: (qmail 43 invoked from network); 19 Feb 2015 21:47: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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y4+5JwWXh38BfTpmUtaPgMtwymOr9Wh9XSEfkqDptUg=; b=iCGqpD4xlWk37KXzI4waM0cvnPJrDftMn7u5sq7XW9L92TpJXF71zxuMG1gDZ3Myb1 uF5LJD2xzklZ0HkwNG6lBvrCLDUpSPvA6l4zis0MpP2ReBd9G/LnMpQ0ePCOMeFKb9Wm jffmSstQlqjf+acA303Ww3xBCR3mJS4gScuEYM+7Xz5lu841orrZALXiHGtx0asaljGE OyBKoLxOj+ISQpOdvdLHHbnwsB1/7QGeYJ5BL/Y3q5fNXcQVhxutSqBiuI0A7tTXpiyd wunS5RAFmSBxQTe0j/iT8UMu9tTB305K4N7Htto6ITQbG5+C00KVGgvPAXpNlpmu2lQV Rn7w== MIME-Version: 1.0 X-Received: by 10.50.114.4 with SMTP id jc4mr131687igb.14.1424382432434; Thu, 19 Feb 2015 13:47:12 -0800 (PST) In-Reply-To: <20150219101315.477f7f95@pwslap01u.europe.root.pri> References: <20150219101315.477f7f95@pwslap01u.europe.root.pri> Date: Thu, 19 Feb 2015 22:47:12 +0100 Message-ID: Subject: Re: PATCH: parse from even deeper in hell From: Mikael Magnusson To: Peter Stephenson Cc: "Zsh Hackers' List" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2015 at 11:13 AM, Peter Stephenson wrote: > And Tomlinson looked down and down, and saw beneath his feet > The frontlet of a tortured star milk-white in Hell-Mouth heat. > > % print $((echo one); (echo two)) > zsh: bad math expression: operator expected at `one); (ech...' > > At the point this goes wrong, we've actually already established this is > a command substitution, not a math expression. However, we're now in > the substitution code and it doesn't have any marker that that's > happened. Instead, it just looks to see if there are two parentheses at > the end, which there are. > > Note that it's not a fix to count active parentheses in the middle at > that point: those aren't tokenized because we're parsing this as a > string for later expansion. So the ones at the end are the first that > skipparens() picks up. In any case re-counting when we've already > established what's supposed to happen is a pretty kludgy fix. > > The fix here is to use different tokens for the first and last > parenthesis for math. We then just look for the matching close marker > when we find the open marker. We can't have nested math expansions so I > think this ought to be robust. > > I've incremented the version as this changes the way strings are > tokenized. > > The tests might more logically be with command substitution rather than > arithmetic, but I've left them in order to keep the tests for is / isn't > arithmetic in one place for easy comparison. I get a crapton of "bad(2) wordsplit reading history:" with this patch. It seems like all the failed lines have metafied characters in them, if that's a hint. Most don't contain any syntax characters at all, for example: hist.c:3499: bad(2) wordsplit reading history: mp3info =E5=A5=BD=E3=81=8D= =E3=81=AB=E3=81=AA=E3=82=8A\M-c\M-^A=E3=81=84.mp3 at: =E5=A5=BD=E3=81=8D=E3=81=AB=E3=81=AA=E3=82=8A\M-c\M-^A=E3=81=84.mp3 word: =E5=A5=BD=E3=81=8D=E3=81=AB=E3=81=AA=E3=82=8A\M-c\M-^A=E3=81=84.mp3 The (2) means it's the second of the two bad=3D1; assignments triggering. (Left over from last time I had a problem in that area). I'm also not sure why the utf8 is slightly mishandled in the output there. It has at least been unmetafied, the raw string in the history file is more or less: mp3info =E5=A5=BD=E3=81=83=EF=BF=BD=E3=81=AB=E3=81=AA=E3=82=83=EF=BF=BD=E3= =81=9F=E3=81=83=EF=BF=BD.mp3 --=20 Mikael Magnusson