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
next 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).