[Toybox] "bad xform" not very helpful

[Rob Landley]

On 9/1/22 15:49, enh wrote:
>     The downside of doing that is it would require TOYBOX sed. 
> 
> meh, _i_ don't care about that :-)
> 
> (and, more seriously, does _anyone_ care about using a mixture of toybox and
> non-toybox?

At the command level, sure. On macos and bsd you're still using the host "ps"
because those environments have a very different API from Linux for getting that
information. Commit 61ef1dccec4e removing getprop/setprop from toys/android was
an example of cleaning up AFTER "you could use the toybox or non-toybox version
of things" letting you easily change that decision after the fact.

Commands calling other commands is sort of a meta-level of this. It's not a
common use case, but the ability to mix and match is sort of a design hygiene
thing. When mount calls losetup or swapon, I don't want to _require_ that be the
toybox one because you might need "swapon -L LABEL" which I haven't implemented
yet, so on your system you've installed another implementation, and if that's
the only one in the $PATH it should still work.

Toybox is an implementation of a set of commands. They're bundled together into
a single executable because doing that makes a significantly smaller binary
footprint (both in storage and at runtime) and has some other advantages, but it
was never intended to REQUIRE you to use choose all toybox or all not-toybox. If
somebody needs a feature only available in gnu/tar they should be able to
install that alongside toybox but have it call our gunzip, and people install
Julian Seward's bzip2 package because they need the compression side or the
shared library so toybox tar should be able to use that bzcat rather than
requiring both implementations to be installed. I don't want anybody to feel
they're locked in to toybox because of bundling, I want it to be the best fit
for their needs.

That said, this one isn't a big objection. Saying "I can't think of a better
design than adding a bespoke talk-to-tar I/O protocol to sed" is similar to me
saying "I broke down and rewrote diff from scratch". Minor grumble, I'm not
proud of it, I would rather have come up with something more clever, but that's
not going to stop me from doing it. This is the best way I've come up with to
accomplish my goals. Bit disappointed in myself I couldn't do better, but eh.
Happens.

That said, I want it to fall back to provide as much functionality as it does
now when sed --talk-to-tar errors out because it's not our sed. :)

> i'd imagine the only people who'd even notice would be people like
> me [or these kernel guys] trying to switch over, and the only reason i/they are
> switching over one tool at a time is because we've been running slightly ahead
> of you, using stuff that's not finished yet.

It should still be policy after the 1.0 release. I can't always achieve
interoperability or compatibility, but I would like to where possible.

> i guess it would affect the toybox
> _tests_ but i kind of thing that's a bug already --- given that i support
> systems where everything's from toybox it's a misfeature that the toybox tests
> _don't_ test toybox-with-toybox [and i get no value from them testing
> toybox-with-gnu].)

That's to make sure the tests are real. "It produces the output I told it to
produce" is a tautology. The code I wrote passing the tests I wrote does not by
itself give me confidence I've actually _proven_ anything. The "IETF bakeoff"
approach of two different implementations interoperating is a much stronger
statement: not always achievable, but nice when it is.

Also, as annoying as it is when host upgrades break the tests... that's kind of
a thing I need to know, and I've tweaked toybox to match what the host is doing
now on multiple occasions.

Rob