Using less in environment without controlling tty

Harald Becker ralda at
Sat Jul 27 17:53:30 UTC 2013

Hi Laurent !

On 27-07-2013 05:42 Laurent Bercot <ska-dietlibc at>
>> 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?
> Ah, I was assuming you had full control on console_buffer,
>which is for instance a C program. If you only have access to
>executables and shell commands, yes, it is more complicated.
> Shameless plug: execline makes opening anonymous pipes and
>redirecting fds much easier than the shell does.

console_buffer is a C program of mine, but it's purpose is to be
general usage. As this I do not want to throw in code to work
around this single problem. Especially as it seems it is a
Busybox related problem. The original less uses just stdout for
it's display, if stdout is a tty.

In case anybody is interested, I attach the source of
console_buffer.c, a (yet) uncommented quick hack for a general
purpose problem: If you want to catch your console output, but
don't like (or not available) to write output to a file at the
start of operation. console_buffer allows to catch the output in
memory and decide what to do just before exit (discard, write to
stdout, write to a file, or pipe to any command).
>> Which tests? ... and how are you able to burn your system,
>> other than you are always able (like cat >ANYWHERE)?
> Oh, I just meant that termios would fail and since the return
>codes are not tested (because they are assumed to work at this
>point) less would just do ugly things. Nothing too serious.

Ok, that's why I called it a temporary fix, and did not provide a
patch to change things. I know there are open questions, to be
clarified before we modify mainstream.

>> 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?
> isatty(1) should be enough indeed. No idea why busybox does
>things differently.

After looking in this, I suggest using stdout for display, which
is tested with isatty a few lines above. Currently stdout needs
to be a tty to let Busybox enter the interactive mode (less, else
just like cat), but Busybox does not use this tty on stdout, it
tries to open /dev/tty. Why? For what purpose? There is no
comment on this, so I'm asking?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: console_buffer.c
Type: text/x-csrc
Size: 4550 bytes
Desc: not available
URL: <>

More information about the busybox mailing list