Using less in environment without controlling tty

Harald Becker ralda at
Fri Jul 26 22:47:33 UTC 2013

Hi Laurent !

> What you need is simply to have a terminal to display your
>messages to. You could use the openvt command (included in
>busybox) for that:

> say console_buffer forks display_prog if there are errors,
>make it fork "openvt display_prog" instead.

console_buffer forks "sh -c COMMAND", where COMMAND is send
to console_buffer dynamically.

> Since openvt
>redirects stdin, stdout and stderr to the terminal you get,

Same problem as using cttyhack :(

>you'll need to pipe the data via another fd. For instance,
>making console_buffer's child read its data on fd 3 and using
>"openvt sh -c 'exec display_prog <&3'" should do the trick.

And how is the data pipe to fd 3? The intention is to pipe all
messages to stdin of the invoked program. This is the way normal
pipes work. So this would need heavy fiddling with the file
descriptor redirecting. Very hard to do in shell programming and
very much overhead to just open a device for display?

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

Which tests? ... and how are you able to burn your system, other
than you are always able (like cat >ANYWHERE)? And what about
original less, it seams it doesn't have the problem on
using /dev/tty ... I'm able to load original less in this
situation to display the messages without problems
( "|/usr/bin/less >/dev/ttyN" ), but this needs the availability
of less (and libraries) which are not available on initial steps
of startup. So why does Busybox less needs extra tests, not
required for original less?

... and what more do we need to test than just setting termios on
the given fd? If this fails we do not have a terminal ... and may
fall back to cat operation.


More information about the busybox mailing list