[Toybox] Article about toybox in h-online.

[Rob Landley]

On 03/07/2012 05:30 AM, Paul Onyschuk wrote:
> Worth reading, thanks for taking your time to do interview.  Below are
> some of my comments.
> 
> As for bionic libc, take your time.  There is high chance that musl
> libc could be relicensed [1] on more permissive terms.

Oh wow.  Yeah, that would totally be a big deal and I'd probably try to
switch aboriginal linux over to testing musl the same way I'm gradually
replacing busybox with toybox.

> This is better
> opportunity, because with bionic libc you would need to practically
> fork it without upstream support.

That's one of the big reasons I wasn't interested in trying to extend
android's toolbox.

>  You look like a busy man anyway, but
> you especially shouldn't be in hurry in this case.  I'll probably look
> myself at using musl libc in Aboriginal Linux.

Cool.  Thanks.

(I'm told they were using aboriginal to add arm support to musl.  In
theory you should only have to add a new sources/sections/musl.build and
change the "build_section uClibc" lines to say musl instead.  I tried to
make it reasonably self-contained...)

> When it comes to list of commands for toybox, I think there is one on
> list, that shouldn't be - man(1).  It is pretty useless on its own.  I
> can think only of one scenario, where run time dependency isn't needed
> for man(1), but it is obsolete nowadays.  Catpages are pre-formatted
> man pages (e.g. "groff -Tascii -mandoc page.1 | gzip > page.1.gz").
> They used to be shipped, because some platforms where to slow to format
> bigger man pages on demand (e.g. shell man page on VAX).

cat pages was mostly what I was thinking of.  Part of the problem is
that toybox isn't _creating_ man pages in troff+cruft format, so an
external man utility would have trouble interfacing with our "help" stuff.

Note that when you're running bash, you've got a "help" command listing
all the builtins.  So "help wait" gives you the wait shell command, "man
wait" gives you the system call.  help pushd gives you a page and change
of docs, man pushd gives you nothing.

(Of course this being the FSF they implemented a lot of stuff in bash
_and_ in coreutils, so the man pages of time, echo, and kill exist, but
probably aren't what you're using unless you say "/bin/echo".  For the
first few ubuntu releases, the /bin/echo provided by ubuntu didn't
support -n and -e, but this didn't matter because the one in bash was
always used... until they switched to the Defective Annoying SHell...)

> Other than that groff or replacement for it is needed to use man(1).  I
> don't think that is valuable option for writing man(1) implementation
> in C.

I want a man command that:

A) shows the help entries for the builtin stuff.
B) cats the catpages out of the appropriate /usr/share/thingy directory,
C) optionally falls back to trying an external man command if neither of
those work.

I'm not particularly interested in implementing troff.  It isn't used
for anything else these days.  There's still a tr command in susv4 so
maybe someday a simple one, but between doclifter and the masters moving
to xml these days...

>  This can be done by trivial shell script, beside man(1) has
> other friends like apropos(1) and this is available in separate
> packages.
> 
> I forgot to mention that man pages are usually compressed on end user
> system, so this is another run-time dependency.

I've already got bunzip2 (I wrote one, and wrote most of a bzip2 as
well) and I plan to write my own gzip and gunzip implementations.  Dunno
about xz yet...

>  This can be also
> problematic: which format is used for archives and which commands are
> available to uncompress them.

Nah, tar's gotta deal with that anyway so this isn't a new problem.

Rob