Re: Terminal I/O handling fix

[P.Stephenson@swansea.ac.uk]

coleman@math.gatech.edu wrote:
> > The difficult case is `exec < file' since that's supposed to change
> > where commands are being read from.  In fact, if zle was being used,
> > it always attempted to use zle to read from the file.  I've put an
> > explicit test in execcmd() for this, so that if commands are
> > notionally coming from stdin in an interactive shell and you do 'exec
> > < file' it tries to work out what to do.  The case where `file' is
> > actually a terminal is the hardest, since then there's in principle a
> > lot more work to do.  In fact, all I've done is re-open the terminal
> > files (so that exec <$TTY to fix up your terminal works like it always
> > did, in fact now it always makes editing work sensibly which it didn't
> > before when stdout was also used).  Ideally this probably needs to be
> > more sophisticated, or combined with the code in setmoreflags() which
> > sets up terminal handling initially.  (At the moment that does other
> > things, which is why I didn't use it.)
> 
> This is the part that I like the least.  I'm wary of adding more tricky
> logic to exec.c since it's basically incomprehensible already.  I've
> started a little cleanup of the tty initialization in setmoreflags in
> beta9-test5 (which unfortunately causes your patch to fail, but it
> is easy to fix by hand).  What type of things would need to be added
> here to fix the problems you are talking about.  I guess I don't
> understand the issues involved.

I agree it would be an improvement to have this code in some function
rather than in execcmd(). I don't think there's anything basically
wrong with setmoreflags(); I should think adding a few more checks for
things which were done already would do the trick, such as

(1) the malloc(BUFSIZ)'s (I don't know if you need to call setbuffer
again, but presumably it's harmless as long as you keep a static
variable for the buffer --- though if it does need redoing, the right
time is presumably when fd's 1 and 2 change, not 0)

(2) checking shout/SHTTY and closing them if they're already open
(though if you fclose(shout) you won't need to close(SHTTY),
presumably)

(3) moving out that `subsh = 0' (don't quite know what it's doing,
shouldn't it always be 0 at that point if it needs to be?).

At a cursory look, anything else can be stand to be done over again
(and probably should be if the shell's stdin changes).  Probably
setmoreflags() could then become initterm() or something like that;
perhaps it's natural place is then next to setterm() in zle_main.c.

Then changing the block following the `if (nullexec ... interact)'
added in execcmd() to call the revamped function ought to work.  If
`exec <...' is to work properly, I think some test or other at that
point is inescapable.

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.