Re: odd script(1) behavior - script bug, man bug, ?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B