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

[enh]

On Sun, Jan 20, 2019 at 10:06 PM Rob Landley <rob at landley.net> wrote:
>
> 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

yeah, i'm pretty sure we already use prebuilts for the JDK and there
_are_ prebuilts for python, so presumably we use those too. dunno
about openssl, but obviously not your problem.

> 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

yeah, cp had the symlink issue (i just switched us back over so
hopefully it sticks this time), date has all the weird shit that i
need to wade through at some point, find is at the bottom of my list
because it was the first thing i had trouble with when i
_accidentally_ tried to use toybox to build AOSP, grep i haven't
looked at yet because i feel weird saying "it's not ready to replace
BSD grep on the system but, hey, who cares about the build?", hostname
just went back in with my DNS/jail fixes, patch looks like a pain,
realpath i have notes saying "-s and --relative-to" but haven't looked
at writing the patch yet, the sed with the -i and -z fixes seems to be
failing obscurely and the build server isn't giving me enough^Wany
information about what's wrong so that'll take more local prodding,
timeout needs a bunch of missing options, and my notes claim tr is
still in pending, and my checkout seems to agree.

> 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

yeah, i don't want to have to deal with the inevitable fallout if you
rewrite these.

plus xz we actually have "real" xz in the tree, so i assume we'll just
have a prebuilt of that.

> 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

awk we have one-true-awk (though i'm trying to work out why i breaks
the build), m4 we have the GNU m4 because apparently the user(s) make
heavy use of some kind of huge m4 standard library. the zip stuff
we'll probably use libziparchive-based tools to match the platform.

> 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