Using less in environment without controlling tty

Denys Vlasenko vda.linux at googlemail.com
Sun Jul 28 20:54:32 UTC 2013


On Saturday 27 July 2013 01:14, Harald Becker wrote:
> Hi Laurent !
> 
> >> My current (temporary) fix for this is, to patch Busybox to use
> >> fd #2 (stderr) als kbd_fd (kbd_fd = 2;) then it is possible to
> >> redirect output of less to any location you like:
> >> 
> >>  ... | less 2<>/dev/ttyN
> >
> > The problem of this approach is that it bypasses the built-in
> >tests in less, so if someone on your system uses less on a
> >non-terminal fd, it will crash and burn ^^
> 
> I just looked into source of less ... it uses fd 1 (stdout) for
> it's display and behaves like cat if fd 1 is not a tty. Why
> can't we follow this principle in Busybox. Why do we need to
> explicitly do an open on /dev/tty?

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.

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

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

Setting stdout to nonblocking mode will affect other its users.

$ prog | less
$ <oops, shell's stdout is in nonblocking mode. mass confusion>

Unfortunately, result of dup(fd) is still aliased to fd.
Nonblocking mode will affect it too.

open("/proc/self/fd/1")? Gaack...


More information about the busybox mailing list