Using less in environment without controlling tty

Harald Becker ralda at
Mon Jul 29 13:37:04 UTC 2013

Hi Denys !

>We need to get keyboard input from some fd to navigate in less.
>In "PROG | less" situation, stdin is the output
>of PROG, it is not a suitable source to read keyboard input from.

Nobody asked to use stdin for display of messages. We are talking
about using stdout (or stderr). The full less program uses stdout
and you can do:

PROG | /usr/bin/less 1<>/dev/ttyS2

>Current code obtains such fd by opening "/dev/tty".

Which can't be assigned to in any way from within normal shell
scripts :(

>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? Full screen terminal
input (e.g. for editors) work in raw tty mode with blocking I/O.

>Setting stdout to nonblocking mode will affect other its users.

If fd is duped, yes this a known issue.

>$ 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). If less turns
the tty back into blocking I/O before it exits, the shell shall
not see any difference in usage, than before invocation of less.

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. 


More information about the busybox mailing list