Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Zsh 3.1.6 - ${~foo} expansion bug
- X-seq: zsh-workers 9613
 
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
 
- To: zsh-workers@xxxxxxxxxxxxxx
 
- Subject: Re: Zsh 3.1.6 - ${~foo} expansion bug
 
- Date: Mon, 7 Feb 2000 21:19:29 -0800
 
- Cc: Jukka Laurila <jplauril@xxxxxxxxx>
 
- In-reply-to: <mvbya8wppr8.fsf@xxxxxxxxxxxxxxxxxxxx>
 
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
 
- References: <Pine.OSF.4.10.10002072343280.17515-100000@xxxxxxxxxxx> 	<mvbya8wppr8.fsf@xxxxxxxxxxxxxxxxxxxx>
 
On Feb 8, 12:16am, Alexandre Duret-Lutz wrote:
> Subject: Re: Zsh 3.1.6 - ${~foo} expansion bug
>
> From my experiments I am tempted to deduce that this is
> reproducible as long as you don't call a builtin before
> the for loop.
This is exactly correct; I recompiled with --disable-zshenv to be
absolutely certain that no commands were executed by "zsh -f",
and now I can reproduce the problem as well.
Tracing through, I find that after a builtin has been executed,
the `esglob' == 1 at exec.c:1516.  The first time through the "for"
loop, when it misbehaves, `esglob' == 0.  And sure enough, esglob
is a static which is not initialized until execcmd() is called.
I imagine there some similar problem with `esprefork'.  I don't
know where these should be getting initialized, though, nor what
the right starting value for `esprefork' should be, though `esglob'
clearly ought to be initialized to 1.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author