zsh-users
 help / color / mirror / code / Atom feed
From: Bernd Eggink <eggink@uni-hamburg.de>
To: Zsh Users <zsh-users@sunsite.auc.dk>
Subject: Re: vared bug
Date: Mon, 14 Aug 2000 10:02:09 +0200	[thread overview]
Message-ID: <20000814100208.A21719@eggink4.rrz.uni-hamburg.de> (raw)

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


             reply	other threads:[~2000-08-14  8:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-14  8:02 Bernd Eggink [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-08-07 14:23 Bernd Eggink
2000-08-07 16:19 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000814100208.A21719@eggink4.rrz.uni-hamburg.de \
    --to=eggink@uni-hamburg.de \
    --cc=zsh-users@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).