From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-34321-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 2315 invoked by alias); 18 Jan 2015 17:32:05 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 34321
Received: (qmail 3209 invoked from network); 18 Jan 2015 17:32:02 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
X-Originating-IP: [86.6.153.127]
X-Spam: 0
X-Authority: v=2.1 cv=AoZg3YNP c=1 sm=1 tr=0 a=39NrsSuza2clQiZR/7fYWQ==:117
 a=39NrsSuza2clQiZR/7fYWQ==:17 a=IkcTkHD0fZMA:10 a=NLZqzBF-AAAA:8
 a=q2GGsy2AAAAA:8 a=-O3KiAGxQpI9OlfupZMA:9 a=QEXdDO2ut3YA:10
Date: Sun, 18 Jan 2015 17:31:57 +0000
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Command substitution parsing issues (not really Re: completion)
Message-ID: <20150118173157.184e385f@ntlworld.com>
In-Reply-To: <150116185732.ZM30791@torch.brasslantern.com>
References: <54B9AA99.6080403@eastlink.ca>
	<150116185732.ZM30791@torch.brasslantern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 16 Jan 2015 18:57:32 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I still get:
>=20
> schaefer<501> echo =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF$(ls)
> Completing all expansions
> =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF$(ls)
> Completing original
> $(ls)

I've narrowed this down (note no completion in the following repro,
hurrah):

% alias foo=3D'echo poop'
% echo ${(e):-'$(foo)'}
=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF$(foo)

This comes from the call from subst_parse_str() to parsestr() and
parsestrnoerr(), which make unwarranted and undocumented assumptions
about the way the lexer works, in particular that if it passes in a
variable s then any parsing happens within that string --- a pretty
stupid assumption.  The interface needs fixing up, which
ought to be easy enough just by ensuring parsestrnoerr() passes back a
reference to tokstr --- however, I see parsestr is called all over
the place so I'm not going to have time to look now.

We also need to ensure and document that the string parsed in comes from
the heap --- I think that's already a requirement, just nobody got
around to writing it down.  In fact parsestrnoerr() appears to be doing
all sorts of hair-raising things without documentation --- why set the
input string and then immediately after set the lexical buffer to the
original string?

This is nothing fundamentally to do with the rest of the change.  If
anyone else has time, go ahead --- this is killing off my free time at
the moment.

pws