Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!uwvax!oddjob!mimsy!eneevax!umd5!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa Newsgroups: comp.unix.wizards Subject: BSD script program. Message-ID: <7176@brl-adm.ARPA> Date: Wed, 29-Apr-87 19:14:06 EDT Article-I.D.: brl-adm.7176 Posted: Wed Apr 29 19:14:06 1987 Date-Received: Fri, 1-May-87 04:14:17 EDT Sender: news@brl-adm.ARPA Lines: 38 >ever been fixed to work correctly with pipes ... ? Script is not at fault, and there is nothing there that can be fixed. The problem is with the whole notion of `interactivity'. More, vi, and other programs---indeed, all programs that use stdio---assume that if the standard input and output are `typewriters' (if isatty()) is true), the program is interactive. If not, the program is not being used interactively and need not behave interactively. Or more properly, isatty(0) or isatty(1). One way of getting around this is to use a flag as `sh' does (-i) to force `interactivity'. Nor is it clear which of stdin/stdout implys interactiveness. In `sh's case, the test leans toward stdin, while with more, it clearly lies with stdout, which is where `more' reads its commands from. I imagine there is a reason why `stty' refers to its stdout as well. This is fine for grep ... | sed ... | awk ... but fails miserably for script. Short of altering all programs that misbehave, there is nothing that can be done. Ptys work around this; Pty's also solve the ioctl problem as well. In some cases, useful information could be had by looking at stderr. but the more proper solution is to redefine `interactive' and rewrite the system. But I am not going to attempt it. Sounds like a job for Interactive Systems :-) In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu (Root Boy) Jim "Just Say Yes" Cottrell I hope I bought the right relish...zzzzzzzzz..."