* Zsh 3.1.6 - ${~foo} expansion bug
@ 2000-02-07 20:49 Jukka Laurila
2000-02-07 21:40 ` Bart Schaefer
0 siblings, 1 reply; 9+ messages in thread
From: Jukka Laurila @ 2000-02-07 20:49 UTC (permalink / raw)
To: zsh-workers
The following script:
#!/bin/zsh
foo=*
echo
for bar in ${~foo}; do
echo Looping: $bar;
done
works as expected, that is, the wildcard is evaluated in line 4:
nostromo:/tmp/foodir % ls
file1 file2 file3 zshbug*
nostromo:/tmp/foodir % ./zshbug
Looping: file1
Looping: file2
Looping: file3
Looping: zshbug
However, when I remove that redundant-looking 'echo' command...
#!/bin/zsh
foo=*
#echo
for bar in ${~foo}; do
echo Looping: $bar;
done
...the printout changes to this:
nostromo:/tmp/foodir % ./zshbug
Looping: file1 file2 file3 zshbug
...and even stranger, when I additionally change the command
'echo Looping: $bar;' to 'echo Looping: /usr/$bar;' I get:
Looping: /usr/X11R6 /usr/bin /usr/dict /usr/doc /usr/games
/usr/i486-linuxlibc1 /usr/include /usr/info /usr/lib /usr/local /usr/man
/usr/sbin /usr/share /usr/src
Again, putting that redundant echo before the for loop makes the script
behave in the proper way.
These results were obtained with zsh 3.1.6 from the Debian Potato
distribution. When run under zsh 3.0.5-15 from RedHat 6.1 the scripts
produce the expected results (the ones obtained with the redundant echo
command before the loop). It seems that zsh 3.1.6 evaluates wildcards a
bit late in some situations.
---------------------------------------------------------------------
--- If tar, vodka and sauna don't help, then the condition is mortal.
--- +358503312601 - http://www.hut.fi/~jplauril/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
2000-02-07 20:49 Zsh 3.1.6 - ${~foo} expansion bug Jukka Laurila
@ 2000-02-07 21:40 ` Bart Schaefer
2000-02-07 22:29 ` Jukka Laurila
0 siblings, 1 reply; 9+ messages in thread
From: Bart Schaefer @ 2000-02-07 21:40 UTC (permalink / raw)
To: Jukka Laurila; +Cc: zsh-workers
On Mon, 7 Feb 2000, Jukka Laurila wrote:
> These results were obtained with zsh 3.1.6 from the Debian Potato
> distribution.
I can't reproduce this in 3.1.6-pws-1, built myself on RedHat 6.0, nor in
3.1.6-dev-16 from the Mandrake RPM. What is your $ZSH_VERSION ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
2000-02-07 21:40 ` Bart Schaefer
@ 2000-02-07 22:29 ` Jukka Laurila
2000-02-07 23:16 ` Alexandre Duret-Lutz
2000-02-07 23:25 ` Thomas Köhler
0 siblings, 2 replies; 9+ messages in thread
From: Jukka Laurila @ 2000-02-07 22:29 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
On Mon, 7 Feb 2000, Bart Schaefer wrote:
> On Mon, 7 Feb 2000, Jukka Laurila wrote:
>
> > These results were obtained with zsh 3.1.6 from the Debian Potato
> > distribution.
>
> I can't reproduce this in 3.1.6-pws-1, built myself on RedHat 6.0, nor in
> 3.1.6-dev-16 from the Mandrake RPM. What is your $ZSH_VERSION ?
$ZSH_VERSION is 3.1.6-dev-16, and 'dpkg -l zsh' says my zsh is:
ii zsh 3.1.6.pws16-1 A shell with lots of features.
I just tried compiling zsh-3.1.6-dev-17 both with gcc 2.95.2 in my
Debian Potato environment and with egcs-2.91.66 in my RedHat 6.1
environment (using chroot). The one compiled in Potato was broken but the
one compiled in RH 6.1 worked!
Could someone try compiling zsh with gcc 2.95.2 and tell me if it
breaks?
---------------------------------------------------------------------
--- If tar, vodka and sauna don't help, then the condition is mortal.
--- +358503312601 - http://www.hut.fi/~jplauril/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
2000-02-07 22:29 ` Jukka Laurila
@ 2000-02-07 23:16 ` Alexandre Duret-Lutz
2000-02-08 5:19 ` Bart Schaefer
2000-02-07 23:25 ` Thomas Köhler
1 sibling, 1 reply; 9+ messages in thread
From: Alexandre Duret-Lutz @ 2000-02-07 23:16 UTC (permalink / raw)
To: zsh-workers; +Cc: Jukka Laurila
>>> "Jukka" == Jukka Laurila <jplauril@cc.hut.fi> writes:
[...]
Jukka> I just tried compiling zsh-3.1.6-dev-17 both with gcc 2.95.2 in my
Jukka> Debian Potato environment and with egcs-2.91.66 in my RedHat 6.1
Jukka> environment (using chroot). The one compiled in Potato was broken
Jukka> but the one compiled in RH 6.1 worked!
Jukka> Could someone try compiling zsh with gcc 2.95.2 and tell me if it
Jukka> breaks?
I can reproduce this with zsh patched up to date (Debian, gcc 2.95.2).
>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.
~/tmp/tmp % zsh -f 0:10 #27
phobos% f=*
phobos% for i ($~f) echo $i
a b c d
phobos% for i ($~f) echo $i
a
b
c
d
phobos%
~/tmp/tmp % zsh -f 0:10 #27
phobos% gcc
gcc: No input files
phobos% f=*
phobos% for i ($~f) echo $i
a b c d
phobos%
~/tmp/tmp % zsh -f 0:10 #27
phobos% cd .
phobos% f=*
phobos% for i ($~f) echo $i
a
b
c
d
phobos%
~/tmp/tmp % zsh -f 0:11 #27
phobos% /bin/echo
phobos% f=*
phobos% for i ($~f) echo $i
a b c d
phobos%
--
Alexandre Duret-Lutz
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
2000-02-07 22:29 ` Jukka Laurila
2000-02-07 23:16 ` Alexandre Duret-Lutz
@ 2000-02-07 23:25 ` Thomas Köhler
1 sibling, 0 replies; 9+ messages in thread
From: Thomas Köhler @ 2000-02-07 23:25 UTC (permalink / raw)
To: zsh-workers
On Mon, Feb 07, 2000 at 11:30:04PM +0100,
Jukka Laurila <jplauril@cc.hut.fi> wrote:
>
> On Mon, 7 Feb 2000, Bart Schaefer wrote:
>
> > On Mon, 7 Feb 2000, Jukka Laurila wrote:
> >
> > > These results were obtained with zsh 3.1.6 from the Debian Potato
> > > distribution.
> >
> > I can't reproduce this in 3.1.6-pws-1, built myself on RedHat 6.0, nor in
> > 3.1.6-dev-16 from the Mandrake RPM. What is your $ZSH_VERSION ?
>
> $ZSH_VERSION is 3.1.6-dev-16, and 'dpkg -l zsh' says my zsh is:
> ii zsh 3.1.6.pws16-1 A shell with lots of features.
>
> I just tried compiling zsh-3.1.6-dev-17 both with gcc 2.95.2 in my
> Debian Potato environment and with egcs-2.91.66 in my RedHat 6.1
> environment (using chroot). The one compiled in Potato was broken but the
> one compiled in RH 6.1 worked!
What do you mean by "broken"?
> Could someone try compiling zsh with gcc 2.95.2 and tell me if it
> breaks?
It compiled without problems, but it didn't find some modules (for
example zle) while running. Not having tried "make install", I don't
know whether this is an issue or not for a full install
CU,
Thomas [running Debian woody with gcc 2.95.2]
--
Thomas Köhler Email: jean-luc@picard.franken.de | LCARS - Linux
<>< WWW: http://jeanluc-picard.de | for Computers
IRC: jeanluc | on All Real
PGP public key available from Homepage! | Starships
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
2000-02-07 23:16 ` Alexandre Duret-Lutz
@ 2000-02-08 5:19 ` Bart Schaefer
0 siblings, 0 replies; 9+ messages in thread
From: Bart Schaefer @ 2000-02-08 5:19 UTC (permalink / raw)
To: zsh-workers; +Cc: Jukka Laurila
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
@ 2000-02-14 9:13 Sven Wischnowsky
0 siblings, 0 replies; 9+ messages in thread
From: Sven Wischnowsky @ 2000-02-14 9:13 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> Sven Wischnowsky wrote:
> > The initialisation to `1' for esglob in the patch below shouldn't
> > really be necessary, because both es* should be set up when one of the
> > functions calling execsubst() will be called.
>
> This sort of thing really needs more comments, particular at the point the
> variables are declared.
Ok.
Bye
Sven
diff -ru ../z.old/Src/exec.c Src/exec.c
--- ../z.old/Src/exec.c Mon Feb 14 10:03:06 2000
+++ Src/exec.c Mon Feb 14 10:12:58 2000
@@ -1505,6 +1505,11 @@
}
}
+/* These describe the type of espansions that need to be done on the words
+ * used in the thing we are about to execute. They are set in execcmd() and
+ * used in execsubst() which might be called from one of the functions
+ * called from execcmd() (like execfor() and so on). */
+
static int esprefork, esglob = 1;
/**/
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
2000-02-08 9:25 Sven Wischnowsky
@ 2000-02-11 19:27 ` Peter Stephenson
0 siblings, 0 replies; 9+ messages in thread
From: Peter Stephenson @ 2000-02-11 19:27 UTC (permalink / raw)
To: zsh-workers
Sven Wischnowsky wrote:
> The initialisation to `1' for esglob in the patch below shouldn't
> really be necessary, because both es* should be set up when one of the
> functions calling execsubst() will be called.
This sort of thing really needs more comments, particular at the point the
variables are declared.
--
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Zsh 3.1.6 - ${~foo} expansion bug
@ 2000-02-08 9:25 Sven Wischnowsky
2000-02-11 19:27 ` Peter Stephenson
0 siblings, 1 reply; 9+ messages in thread
From: Sven Wischnowsky @ 2000-02-08 9:25 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> 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.
The initialisation to `1' for esglob in the patch below shouldn't
really be necessary, because both es* should be set up when one of the
functions calling execsubst() will be called.
What really confused me is that the test was still in the order in
which it was. I *know* I once changed that -- obviously I didn't send
a patch for it.
Sorry!
Bye
Sven
diff -ru ../z.old/Src/exec.c Src/exec.c
--- ../z.old/Src/exec.c Tue Feb 8 10:16:04 2000
+++ Src/exec.c Tue Feb 8 10:22:15 2000
@@ -1506,7 +1506,7 @@
}
}
-static int esprefork, esglob;
+static int esprefork, esglob = 1;
/**/
void
@@ -1917,10 +1917,10 @@
is_exec = 1;
}
- if (args && (esglob = !(cflags & BINF_NOGLOB))) {
+ if ((esglob = !(cflags & BINF_NOGLOB)) && args) {
LinkList oargs = args;
globlist(args);
- args=oargs;
+ args = oargs;
}
if (errflag) {
lastval = 1;
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-02-14 9:13 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-07 20:49 Zsh 3.1.6 - ${~foo} expansion bug Jukka Laurila
2000-02-07 21:40 ` Bart Schaefer
2000-02-07 22:29 ` Jukka Laurila
2000-02-07 23:16 ` Alexandre Duret-Lutz
2000-02-08 5:19 ` Bart Schaefer
2000-02-07 23:25 ` Thomas Köhler
2000-02-08 9:25 Sven Wischnowsky
2000-02-11 19:27 ` Peter Stephenson
2000-02-14 9:13 Sven Wischnowsky
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).