Using less in environment without controlling tty
Denys Vlasenko
vda.linux at googlemail.com
Mon Jul 29 14:10:02 UTC 2013
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
More information about the busybox
mailing list