From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-3364-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 3852 invoked from network); 14 Aug 2000 08:04:12 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 14 Aug 2000 08:04:12 -0000
Received: (qmail 28760 invoked by alias); 14 Aug 2000 08:03:30 -0000
Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 3364
Received: (qmail 28752 invoked from network); 14 Aug 2000 08:03:29 -0000
Date: Mon, 14 Aug 2000 10:02:09 +0200
From: Bernd Eggink <eggink@uni-hamburg.de>
To: Zsh Users <zsh-users@sunsite.auc.dk>
Subject: Re: vared bug
Message-ID: <20000814100208.A21719@eggink4.rrz.uni-hamburg.de>
Mail-Followup-To: Zsh Users <zsh-users@sunsite.auc.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i

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