Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: vared bug

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

Messages sorted by: Reverse Date, Date, Thread, Author