Using less in environment without controlling tty

[Denys Vlasenko]

On Mon, Jul 29, 2013 at 3:37 PM, Harald Becker <ralda at gmx.de> wrote:
>>We can try to use stdout, I suppose, but there are problems.
>>Currently we set kbd_fd to nonblocking mode, for very good
>>reasons (we don't want to block waiting for keyboard input).
>
> Why do we need nonblocking I/O in less?

Because I don't want to wait 999 seconds in this case
before keys start working:

{ echo line1; sleep 999; echo line2; } | busybox less

>  Full screen terminal
> input (e.g. for editors) work in raw tty mode with blocking I/O.

They don't need to consume from two fds at once. less needs that.

>>$ prog | less
>>$ <oops, shell's stdout is in nonblocking mode. mass confusion>
>
> Why shall this produce any trouble? Shell forks two processes for
> the pipe, then waits until those processes finish. Normally it
> shall not fiddle with any input from tty until the less program
> finished. less may switch tty to nonblocking mode, but needs to
> switch back on exit (like other termios settings).

How to reliably do that? You can't win against, say, SIGKILL.

> The confusion only occurs, when less dies without restoring
> settings ... which is a known issue, with all kinds of trouble.
> Usually you need to do a tty reset, before you can continue
> normal work, in that case. ... but this is a failure in restore
> before exit.

Exactly. Stdout can be messed up on exit.

Need to weight the possibility of less messing up stdout
against the possibility that ctty is not available.

Since w/o ctty, there will be other problems as well
(environment where ^C doesn't work isn't fun to work in),
it is not clear that it is worthwhile to support that case.

Why can't you acquire a ctty?

-- 
vda