>>> Does script(1) (not specified by POSIX) require that stdin is a >>> tty? >> In practice, I think so. [...on NetBSD...]
I have since tried this on a work Ubuntu machine, and it "works". That is, "cat | script -c sh | cat" (-u not necessary, turns out) gives an interactive shell that accepts commands and returns results like any other shell. > I read the code some, and believe > - the ioctl failure is a clue that the author expected that stdin > is a tty, Well, not necessarily that; perhaps just wanting to handle the case where it is (which is not surprising; if nothing else, I'd expect stty settings to be pushed down to script's pty). > but is not relevant to the behavior (retval not checked) Hm, depending on the surrounding code, that may or may not be a separate bug. > - the main loop reads from stdin and when that hits EOF, the > top-level process exits Not relevant to the "cat | script | cat" tests, I think, because script's stdin shouldn't get EOF. > - the child processes continue until the shell/command is done > - normally this exit/continue/exit is very fast as the command is a > shell that exits on EOF Yes, but why would the shell get EOF? script hasn't got EOF, and ktrace says it hasn't done anything to the pty to cause the pty to give EOF to the shell. I'd need to either ktrace the whole thing (as in ktrace -d sh -c "cat | script -c sh | cat") or add debugging code and rebuild script, because there's clearly something wrong with the above analysis, but I currently have no idea what. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
