Using less in environment without controlling tty

Denys Vlasenko vda.linux at
Mon Jul 29 23:35:29 UTC 2013

On Monday 29 July 2013 16:46, Harald Becker wrote:
> 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.

select/poll should still use nonblocking fds, it does not guarantee
that read will succeed.

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

Try the command. You will see that line2 appears by itself
(no need to press anything).

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

It doesn't handle it. It will block on read from stdin.

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

I don't think that not having a tty is a normal use case.

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

I still don't understand why don't do you just give
poor thing its ctty to be happy with.

I just tried this:

setsid sh -c 'exec </dev/tty12 >/dev/tty12 2>&1; exec less FILE'

and it worked (both setsid and less are bbox applets here).


More information about the busybox mailing list