[Toybox] [PATCH] hostname: fix behavior when in jail.

[Rob Landley]

On 1/20/19 4:20 PM, enh wrote:
> the link in the roadmap (the checked-in copy; the web site is too old)
> is, for better or worse, a link to the current status:
> https://android.googlesource.com/platform/build/soong/+/master/ui/build/paths/config.go

It looks like the remaining commands are:

  awk bash bc bzip2 cp date dd diff egrep find fuser getopt git grep gzip
  hexdump hostname jar java javap lsof m4 openssl patch pstree python python2.7
  python3 realpath rsync sed sh tar timeout tr unzip xz zip zipinfo

Triage:

All this is out of scope for toybox:

  openssl jar java javap python python2.7 python3

The ones that should work already (or are probably trivially fixable, send test
cases) are:

  cp date egrep find grep hostname patch realpath sed timeout tr

These are in pending and complete-ish but I need to go over them. (They probably
work but are all in pending for a _reason_):

  bc dd diff lsof tar xz

These are todo list items I haven't properly started yet but more or less know
how to do. (I could say more about any of these if asked.)

  awk bash/sh getopt git m4 pstree rsync unzip zip zipinfo

fuser is just a lsof variant, adding that's part of my cleanup todo list for
that command.

I already wrote most of hexdump -C, do you need any hexdump other than -C? (If
so it shares code with _3_ other commands, od xxd and hexedit, and should be
collated.)

About the archivers: bzip2, gzip, xz, tar, unzip, zip, and zipinfo are
conceptually related and sort of one big todo item.

I have decompression side code for bzip2, gzip, and xz in the tree already. (In
fact I wrote the code the kernel was using for bzip2 decompression. The xz one
is a public domain implementation in pending, but it worked last I checked.)

But on the compression side, only gzip (the "deflate" algorithm) is in scope for
toybox. (Toybox should have a compressor and that's the simplest one. For the
others it should be able to extract the file formats, but doesn't necessarily
need to create them.)

I've only really tested "zcat" and friends. (I think I wrote the "replace
blah.bz with blah" versions? But didn't _use_ them much.) The problem is there's
a name conflict if I add a "bzip2" that can only decompress: I then can't have
the full compressor in the $PATH alongside it. I could supply zcat, bzcat, and
xzcat without name conflicts, but not the commands that do both sides. If I go
there, I probably need to do the "hand off to second instance in the $PATH"
thing that ccache and distcc do when it detects you've asked for compression it
doesn't support. :)

The other problem was busybox tar used the built-in busybox compressors, and if
you config those out it didn't know how to call an external one (if you switched
off bzip support busybox tar lost -j), so as long as aboriginal linux was still
using busybox tar, toybox bzcat wasn't helpful. I needed to cleanup/promote tar
to enable toybox's existing decompressors in aboriginal linux. I don't use
aboriginal anymore and I think busybox fixed that upstream anyway (I know I
complained at 'em about it), and it wasn't a blocker anyway, just "that's why I
hadn't gone down that path yet: work needed to be done as a big lump".
Simiilarly, the zip/unzip/zipinfo implementations are next up after gzip
compression side. (Although "zip encryption" is probably out of scope? Or at
least I hadn't found a need for it yet...)

Anyway, that's why the archivers weren't higher up on the todo list...

Rob