vared bug

vared bug

[Bernd Eggink]

Hi workers,

please try this script:

    function f
    {
       read "dat?What: "
       print -u2 "dat=$dat"
    }

    print $ZSH_VERSION
    P=aha
    vared P
    print "P=$P"
    W=$(f)

The prompt "What: " in the read command isn't shown. This
only happens after a preceding 'vared'. If you comment out
the 'vared' line, it works. 
The bug is in zsh-3.1.9 ... 3.1.9-dev-4.

Regards,
Bernd

-- 
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html

Re: vared bug

[Bart Schaefer]

On Aug 7,  4:23pm, Bernd Eggink wrote:
} Subject: vared bug
}
}     function f
}     {
}        read "dat?What: "
}        print -u2 "dat=$dat"
}     }
} 
}     print $ZSH_VERSION
}     P=aha
}     vared P
}     print "P=$P"
}     W=$(f)

This bug affects 3.0.8 as well.

What's happening is that vared invokes zleread(), which initializes shout
from SHTTY (shout was previously NULL).  The same thing happens if you use
just plain "read" -- e.g., replace "vared P" with "f" above -- so this is
not a problem with vared specifically.

Then $(f) goes through entersubsh(), which closes SHTTY, leaving shout
pointing at an invalid file descriptor.

You can see the same effect if you comment out "vared P" and then run that
script in an interactive shell with "source scriptname".

The question:  Is it intentional that entersubsh() leaves shout pointing
at an invalid file descriptor?  There are a number of places in the code
that blindly write to shout without testing whether it is NULL, so the
effect of close(SHTTY) is that those bits of code silently fail.  If we
assign shout = NULL in entersubsh(), those bits would dump core instead.

I suspect that it's OK to zero shout in entersubsh(), because if we'd
never passed through vared or read it would have been NULL anyway, at
least in a non-interactive shell.  The case I'm worried about is whether
entersubsh() from an interactive shell leaves other state unchanged (the
same way it left shout unchanged) that might permit some of those writes
to shout to occur.  Probably not, though.

Index: Src/exec.c
===================================================================
@@ -2503,6 +2503,7 @@
     if (!fake)
 	subsh = 1;
     if (SHTTY != -1) {
+	shout = NULL;
 	zclose(SHTTY);
 	SHTTY = -1;
     }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: vared bug

[Bernd Eggink]

On Aug 7,  4:19pm, Bart Schaefer wrote:
> On Aug 7,  4:23pm, Bernd Eggink wrote:
> } Subject: vared bug
> }
> }     function f
> }     {
> }        read "dat?What: "
> }        print -u2 "dat=$dat"
> }     }
> }
> }     print $ZSH_VERSION
> }     P=aha
> }     vared P
> }     print "P=$P"
> }     W=$(f)
> 
> This bug affects 3.0.8 as well.
> 
> What's happening is that vared invokes zleread(), which initializes shout
> from SHTTY (shout was previously NULL).  The same thing happens if you use
> just plain "read" -- e.g., replace "vared P" with "f" above -- so this is
> not a problem with vared specifically.
> 
> Then $(f) goes through entersubsh(), which closes SHTTY, leaving shout
> pointing at an invalid file descriptor.
> 
> You can see the same effect if you comment out "vared P" and then run that
> script in an interactive shell with "source scriptname".
> 
> The question:  Is it intentional that entersubsh() leaves shout pointing
> at an invalid file descriptor?  There are a number of places in the code
> that blindly write to shout without testing whether it is NULL, so the
> effect of close(SHTTY) is that those bits of code silently fail.  If we
> assign shout = NULL in entersubsh(), those bits would dump core instead.
> 
> I suspect that it's OK to zero shout in entersubsh(), because if we'd
> never passed through vared or read it would have been NULL anyway, at
> least in a non-interactive shell.  The case I'm worried about is whether
> entersubsh() from an interactive shell leaves other state unchanged (the
> same way it left shout unchanged) that might permit some of those writes
> to shout to occur.  Probably not, though.
> 
> Index: Src/exec.c
> ===================================================================
> @@ -2503,6 +2503,7 @@
>      if (!fake)
>         subsh = 1;
>      if (SHTTY != -1) {
> +       shout = NULL;
>         zclose(SHTTY);
>         SHTTY = -1;
>      }

Thanks, but now a "vared -c prompt var" causes a
segmentation fault if var is unset...

Regards,
Bernd

-- 
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html