Command List

We have several potential use cases for a busybox replacement, and are using those to determine a consensus on which commands to target for a 1.0 release of an unencumbered busybox replacement package.

Our current candidate list combines the commands toybox already implements, the development environment command list, the toolbox standard commands, the Sony configuration of busybox, and the selected subset of the SUSv4 standard.

Thus the first release of a busybox replacement should include the following commands:

Beastiebox currently implements

Here’s a link to the Beastiebox project: http://beastiebox.sourceforge.net/
which has been proven to be capable to replace busybox, in general.
It mostly consists of BSD sources and contains, according to the homepage:

On the TODO side, the Linux specific commands would need to be implemented
or taken from one of the others (Toybox, Android Toolbox, etc).

It does contain a complete shell (mksh, MirBSD Korn Shell) under a BSD-ish
licence, which can be used as /bin/sh (e.g. on Debian) and is the default
/system/bin/sh on Android ICS and later, even. This is not much bigger than
the sh included with Busybox, Beastiebox (can be disabled in favour of mksh)
and others, but has functions such as command line editing, UTF-8 support,
Tab completion, Korn Shell scripting features ([[, arrays, etc). and is
actively developed on its own.

Use case: provide a self-hosting development environment

The following commands are enough to build the Aboriginal Linux development environment, boot it to a shell prompt, and build Linux From Scratch 6.8 under it. (Aboriginal Linux currently uses BusyBox for this, thus provides a corresponding test environment for toybox.)

This use case includes running init scripts and other shell scripts, running configure, make, and install in each package, and providing basic command line facilities such as a text editor. (It does not include a compiler toolchain or C library, those are outside the scope of this project.)

POSIX-2008/SUSv4

The best standards are the kind that describe reality, rather than attempting to impose a new one. (I.E. a good standard should document, not legislate.)

The kind of standards which describe existing reality tend to be approved by more than one standards body, such ANSI and ISO both approving C. That's why the IEEE POSIX committee's 2008 standard, the Single Unix Specification version 4, and the Open Group Base Specification edition 7 are all the same standard from three sources.

Problems with the standard

Unfortunately, these standards describe a subset of reality, lacking any mention of commands such as init, login, or mount required to actually boot a system. It provides ipcrm and ipcs, but not ipcmk, so you can use System V IPC resources but not create them.

These standards also contain a large number of commands that are inappropriate for toybox to implement in its 1.0 release. (Perhaps some of these could be reintroduced in later releases, but not now.)

Some commands are for a compiler toolchain (ar c99 cflow ctags cxref getcat iconv lex m4 make nm strings strip tsort yacc), which is outside of toybox's mandate and should be supplied externally. (Again, some of these may be revisited later, but not for toybox 1.0.)

Some commands are part of a command shell, and cannot be implemented as separate executables (alias bg cd command fc fg getopts hash jobs kill read type ulimit umask unalias wait). These may be revisited as part of a built-in toybox shell, but are not exported into $PATH via symlinks. (If you fork a child process and have it "cd" then exit, you've accomplished nothing.)

A few other commands are judgement calls, providing command-line internationalization support (iconv locale localedef), System V inter-process communication (ipcrm ipcs), and cross-tty communication from the minicomputer days (talk mesg write). The "pax" utility was supplanted by tar, "mailx" is a command line email client, and "lp" submits files for printing to... what exactly? (cups?) The standard defines crontab but not crond.

Removing all of that leaves the following commands, which toybox should implement:

Random Notes

Can implement incrementally

Rob wrote:

One nice thing about busybox/toybox/toolbox is you can install multiple
implementations side by side, and have what symlinks you create (or what
comes first in the $PATH) determine who is implementing what.

This allows gradual transitions. Each release, we replace a couple more
commands from the old one, until the old one finally isn't being used for
anything anymore and we can uninstall it...