From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gatech.edu (gatech.edu [130.207.244.244]) by werple.mira.net.au (8.6.12/8.6.9) with SMTP id UAA17742 for ; Fri, 26 May 1995 20:14:39 +1000 Received: from math (math.skiles.gatech.edu) by gatech.edu with SMTP id AA25923 (5.65c/Gatech-10.0-IDA for ); Fri, 26 May 1995 06:13:13 -0400 Received: by math (5.x/SMI-SVR4) id AA02957; Fri, 26 May 1995 06:11:41 -0400 Resent-Date: Fri, 26 May 95 11:10:55 +0100 Old-Return-Path: Message-Id: <2795.9505261010@pyro.swan.ac.uk> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Terminal I/O handling fix In-Reply-To: "coleman@math.gatech.edu"'s message of "Thu, 25 May 95 20:34:48 EDT." <9505260034.AA29498@redwood.skiles.gatech.edu> Date: Fri, 26 May 95 11:10:55 +0100 From: P.Stephenson@swansea.ac.uk X-Mts: smtp Resent-Message-Id: <"4Y5b51.0.6k.SbQnl"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/45 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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 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.