On Sat, Apr 23, 2016 at 09:57:12AM -0700, enh wrote: > On Sat, Apr 23, 2016 at 3:06 AM, Rob Landley <[email protected]> wrote: > > Non-pending commands _not_ included in the build: > > > > $ make list_working | tr ' ' "\n" | \ > > egrep -v "^($(./toybox | tr '\n ' '||'))\$" | xargs > > > > $ make list_working | tr ' ' "\n" | \ > > egrep -v "^($(./toybox | tr '\n ' '||'))\$" | xargs > > catv chvt count eject factor fstype fsync halt hello hexedit hostid > > iotop killall5 link login lspci mix mkpasswd nfsmount nproc nsenter > > oneit passwd poweroff readahead reboot reset shred skeleton > > skeleton_alias su switch_root test_many_options unlink unshare uudecode > > uuencode w who > > > > what have we skipped: > > > > You have your own init/login and toybox hasn't completed that circle yet > > anyway (halt/oneit/poweroff/reboot/reset/switch_root/killall5), you > > don't use standard uids (login/mkpasswd/passwd/su/w/who), no vga ttys > > (chvt), I should filter the examples directory out of "list_working" > > (hello/skeleton/skeleton_alias/test_many_options), nfsmount is just a > > todo item in mount (it needs a command that can prompt for password), > > and you have your own non-oss audio layer (mix). > > > > We can also say that count/factor aren't important, blkid covers fstype, > > sync covers fsync (albeit less efficiently, and I'm trying to remember > > if the "fsync /dev/sdb" to flush pending I/O to a specific block device > > is actually supported upstream or was an out of tree patch...), and you > > have the standard cat -v (catv). > > > > That leaves: > > > > eject hexedit hostid iotop link lspci nproc nsenter readahead shred > > unlink unshare uudecode uuencode > > > > The four that jump out at me are link, unlink, uuencode, and uudecode, > > which are in posix. I'm aware ln and rm cover the first two, and base64 > > more or less covers the rest, and yet: > > > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/link.html > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/unlink.html > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uuencode.html > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uudecode.html > > it turns out no-one born later than about 1985 has even heard of > uuencode/uudecode. it has to be explained as "a historic form of > base64". yagni. (bionic also doesn't have the posix a64l/l64a for > similar reasons, although the fact that they explicitly operate on a > static buffer is the biggest nail in their coffin.) > > link/unlink was a surprise to even the old-timers, and seem to offer > nothing other than confusion beyond the well-known ln/rm. yagni.
IIRC, I heard that unlink was intended to avoid the need to sanity-check and escape file names: to delete a file named '-h' or '-f', just run 'unlink -h'/'unlink -f'. Of course, GNU mis-implemented it, so it's useless if it's compatible. link, I can't tell, unless it was the same logic. It's from Issue 5 (Unix 98). > > iotop: If the android kernel doesn't have CONFIG_IRQ_TIME_ACCOUNTING > > enabled, this won't do you a whole lot of good. :) > > > > lspci: most android devices don't have pci busses, but android gets used > > in the embedded space sometimes... *shrug* (I worked on one that did in > > 2012, but the product was doomedish and the company recently got acquired.) > > what we really don't have is /usr/share/misc/pci.ids. See: http://pci-ids.ucw.cz/v2.2/pci.ids http://pciids.sourceforge.net/v2.2/pci.ids (Optionally add .gz/.bz2 for the compressed version.) Dual license, GPL2+ or 3-clause BSD. > > nproc: prints number of CPUs. Might be useful, and is in modern > > coreutils, but you can get the info out of /proc or /sys if you need to. > > "what does number of CPUs mean?" is one of the most popular Android > questions. nproc only gives one of the possible answers, so probably > more harmful than useful. > > > nsenter/unshare: Someday, opening the containers can of worms would be a > > really nice thing for Android to do. But we've talked about how there's > > Much Design Work to do to make that happen. Still, if the kernel > > plumbing's enabled, maybe for O? > > > > readahead: was requested. Seems like a redhat-ism to me. > > for the most part i took the view of "if it's not in the base goobuntu > install, no one cares". (not foolproof, because what's useful on a > developer's workstation and what's useful on Android aren't > necessarily the same, but it's a reasonable place to start.) > When I bothered with things like that (for example, to give Firefox a faster cold start, back when I still thought Firefox worth using), I just cheated and did cat ... >/dev/null. What I've heard gave me the impression that readahead is most relevant for perfomance on hard drives (spinning rust), but it *might* pertain to slow solid state things like SD cards. Thanks, Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
