Using less in environment without controlling tty

[Harald Becker]

Hi Denys !

>> 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

less is a program using more than one one concurrent input, a
candidate for select/poll. In addition it's not less waiting for
data form first process when you block on tty. Here you need
nonblocking on stdin, that is the read side of the pipe. The only
question is when new data is displayed. When it shall update
continuously you need to use select/poll, else you may just wait
until a key is pressed then check pipe status for more data (does
not wait). 

>>  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.

Normal candidate for select/poll. How does standard less handle
this?

>>>$ 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.

Same with so many other applications? We all know the unusable
tty situation, in case an interactive program dies unexpectedly.
In most cases you can try a 'reset' Ctrl-J, but sometimes you
need to relogin. You are trying to catch the worse cases and
block normal use cases (to display messages on any tty without
controlling tty).

>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.

There are cases where those shall not work on tty the message is
displayed. You do not "work" with the environment on the other
tty. Control of your environment may still be on another tty.
Just viewing messages (with scrollback) on a second screen.

>Why can't you acquire a ctty?

1) First use case, ctty is stuck on an internal serial console
and shall not switch for some obscure reasons (not under my
control). So I need to run a blind system startup in pid #1 until
I'm able to activate graphics display and framebuffer console.

Display of messages shall go on framebuffer console, without
changing controlling tty away from serial console.

2) Second use case, is multi head usage. Run shell on any
controlling tty, and view message output on another screen.
Controlling signals like Ctrl-C shall always come from
controlling tty not not from message viewing system.

You block both use cases by enforcing usage of /dev/tty without
possibility to reassign keyboard fd. Standard less does not have
this problem, as it uses stdout.


IMO you mix the two things, controlling tty and interactive
display used for message viewing and keyboard input. In some
cases they are not identical, but using /dev/tty enforces this :(

--
Harald