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

[Greg Troxel <gdt%lexort.com@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> 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.