Re: Zsh 3.1.6 - ${~foo} expansion bug

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Sven Wischnowsky]

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

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Peter Stephenson]

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>

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Sven Wischnowsky]

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

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Bart Schaefer]

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.

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Thomas Köhler]

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

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Alexandre Duret-Lutz]

>>> "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

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Jukka Laurila]

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/

Re: Zsh 3.1.6 - ${~foo} expansion bug

[Bart Schaefer]

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 3.1.6 - ${~foo} expansion bug

[Jukka Laurila]

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/