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