zsh-workers
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: Peter Stephenson <p.stephenson@samsung.com>
Cc: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: PATCH: parse from even deeper in hell
Date: Thu, 19 Feb 2015 22:47:12 +0100	[thread overview]
Message-ID: <CAHYJk3T4yw3cz8o8-EVF8gzN_hi+M4kc92UR-XTaFBsJtDD7qg@mail.gmail.com> (raw)
In-Reply-To: <20150219101315.477f7f95@pwslap01u.europe.root.pri>

On Thu, Feb 19, 2015 at 11:13 AM, Peter Stephenson
<p.stephenson@samsung.com> 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 好きになり\M-c\M-^Aい.mp3
at: 好きになり\M-c\M-^Aい.mp3
word: 好きになり\M-c\M-^Aい.mp3
The (2) means it's the second of the two bad=1; 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 好ぃ�になゃ�たぃ�.mp3

-- 
Mikael Magnusson


  reply	other threads:[~2015-02-19 21:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19 10:13 Peter Stephenson
2015-02-19 21:47 ` Mikael Magnusson [this message]
2015-02-19 22:03   ` Peter Stephenson
2015-02-20  3:16     ` Mikael Magnusson
2015-02-20  3:22       ` Mikael Magnusson
2015-02-20  3:33         ` Mikael Magnusson
2015-02-20  3:43           ` Mikael Magnusson
2015-02-20  4:19             ` Ray Andrews
2015-02-20  9:54               ` Peter Stephenson
2015-02-20 10:00             ` Peter Stephenson
2015-02-20 10:12               ` Mikael Magnusson
2015-02-22 18:26                 ` Peter Stephenson
2015-02-23  9:54                   ` Peter Stephenson
2015-02-23 10:11                     ` Peter Stephenson
2015-02-23 11:35                       ` Mikael Magnusson
2015-02-23 12:36                         ` Peter Stephenson
2015-02-23 12:57                           ` Peter Stephenson
2015-02-23 13:38                             ` Mikael Magnusson
2015-02-23 13:46                               ` Mikael Magnusson
2015-02-23 13:51                                 ` PATCH: Remeta one frame earlier Mikael Magnusson
2015-02-23 13:58                                   ` Peter Stephenson
2015-02-23 14:05                                   ` Peter Stephenson
2015-02-23 14:32                                     ` Mikael Magnusson
2015-02-23 17:32                                       ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHYJk3T4yw3cz8o8-EVF8gzN_hi+M4kc92UR-XTaFBsJtDD7qg@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).