Mouse <[email protected]> writes: >>>> 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.
That's not really works, in that the shell run by script has magically found the tty instead of script(1)'s stdin. >> 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). fair enough. >> - 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. But running script with stdin of /dev/null will 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. In my trace, I'm not sure, but the command being run is a test program which doesn't actually read its input. In normal ops, I'm unclear. > 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. I did ktrace, with stdin as /dev/null, and after read returning exit is called.
