<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 2, 2022 at 5:55 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/1/22 15:49, enh wrote:<br>
>     The downside of doing that is it would require TOYBOX sed. <br>
> <br>
> meh, _i_ don't care about that :-)<br>
> <br>
> (and, more seriously, does _anyone_ care about using a mixture of toybox and<br>
> non-toybox?<br>
<br>
At the command level, sure. On macos and bsd you're still using the host "ps"<br>
because those environments have a very different API from Linux for getting that<br>
information. Commit 61ef1dccec4e removing getprop/setprop from toys/android was<br>
an example of cleaning up AFTER "you could use the toybox or non-toybox version<br>
of things" letting you easily change that decision after the fact.<br>
<br>
Commands calling other commands is sort of a meta-level of this. It's not a<br>
common use case, but the ability to mix and match is sort of a design hygiene<br>
thing. When mount calls losetup or swapon, I don't want to _require_ that be the<br>
toybox one because you might need "swapon -L LABEL" which I haven't implemented<br>
yet, so on your system you've installed another implementation, and if that's<br>
the only one in the $PATH it should still work.<br>
<br>
Toybox is an implementation of a set of commands. They're bundled together into<br>
a single executable because doing that makes a significantly smaller binary<br>
footprint (both in storage and at runtime) and has some other advantages, but it<br>
was never intended to REQUIRE you to use choose all toybox or all not-toybox. If<br>
somebody needs a feature only available in gnu/tar they should be able to<br>
install that alongside toybox but have it call our gunzip, and people install<br>
Julian Seward's bzip2 package because they need the compression side or the<br>
shared library so toybox tar should be able to use that bzcat rather than<br>
requiring both implementations to be installed. I don't want anybody to feel<br>
they're locked in to toybox because of bundling, I want it to be the best fit<br>
for their needs.<br>
<br>
That said, this one isn't a big objection. Saying "I can't think of a better<br>
design than adding a bespoke talk-to-tar I/O protocol to sed" is similar to me<br>
saying "I broke down and rewrote diff from scratch". Minor grumble, I'm not<br>
proud of it, I would rather have come up with something more clever, but that's<br>
not going to stop me from doing it. This is the best way I've come up with to<br>
accomplish my goals. Bit disappointed in myself I couldn't do better, but eh.<br>
Happens.<br>
<br>
That said, I want it to fall back to provide as much functionality as it does<br>
now when sed --talk-to-tar errors out because it's not our sed. :)<br>
<br>
> i'd imagine the only people who'd even notice would be people like<br>
> me [or these kernel guys] trying to switch over, and the only reason i/they are<br>
> switching over one tool at a time is because we've been running slightly ahead<br>
> of you, using stuff that's not finished yet.<br>
<br>
It should still be policy after the 1.0 release. I can't always achieve<br>
interoperability or compatibility, but I would like to where possible.<br>
<br>
> i guess it would affect the toybox<br>
> _tests_ but i kind of thing that's a bug already --- given that i support<br>
> systems where everything's from toybox it's a misfeature that the toybox tests<br>
> _don't_ test toybox-with-toybox [and i get no value from them testing<br>
> toybox-with-gnu].)<br>
<br>
That's to make sure the tests are real. "It produces the output I told it to<br>
produce" is a tautology. </blockquote><div><br></div><div>aye, but that's the point of having the TEST_HOST variant, so we can test wholly alien implementations as a reference point.</div><div><br></div><div>the "some toybox, some host" combination -- while not entirely _un_interesting -- is much more niche combo. but at least it's not a new test combination that's making things worse --- it's just a special case of the existing `make test_foo` scenario where we're mostly _not_ testing toybox.</div><div><br></div><div>we don't have too many issues today that we first find when we run on Android (where ~everything's toybox), and if that ever changes, we can worry about it then.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The code I wrote passing the tests I wrote does not by<br>
itself give me confidence I've actually _proven_ anything. The "IETF bakeoff"<br>
approach of two different implementations interoperating is a much stronger<br>
statement: not always achievable, but nice when it is.<br>
<br>
Also, as annoying as it is when host upgrades break the tests... that's kind of<br>
a thing I need to know, and I've tweaked toybox to match what the host is doing<br>
now on multiple occasions.<br>
<br>
Rob<br>
</blockquote></div></div>