[Toybox] ?from left field

[scsijon]

On 10/22/2014 02:36 PM, Rob Landley wrote:
> On 10/21/14 05:06, scsijon wrote:
>>> Puppy Linux provides both full and Busybox versions of many commands,
>>> with a "wrapper" script that will call either the full or the Busybox
>>> version, depending on the arguments.
>>> The *theory* is that it speeds things up if you only need Busybox.
>>> (In practice, it slows everything down.)
>>> I'd read scsijon's request as asking for something rather like that,
>>> so that (a) toybox handles a call by default, and (b) any options we
>>> can't handle get passed to "the full version".
>>>
>>> Rereading it, I get the impression that he's asking for "prefer external
>>> but fall back to applets if that fails"; but maybe you're reading it
>>> right.
>>>
>>>
>>> Thanks,
>>> Isaac Dunham
>>>
>> What I think I'm considering is basically (b), that if the full command
>> has been installed, it will be used for 'switches that toybox can't
>> handle, allowing that the output structure 'may' be different to
>> toybox's or busybox's; (shouldn't happen but...).
>
> I note that if there are command line options that people actually
> _need_, I can probably implement them.
>
>> If the full package
>> has not been installed toybox's version of the command will be tried
>> first when toybox is installed, otherwise it will try to use busybox's
>> version (of course that has to be installed) if the command is not in
>> toybox, OR as a failsafe it ERRORS to tell the user they need the full
>> package or the switch 'is missing or wrong' (typo's come to mind).
>
> Commands exit with an error when the option parsing fails. I could make
> them exec the first non-toybox version out of the $PATH instead, but I'd
> actually prefer to get bug reports for what other functionality people
> actually use that we might want to implement.
>
> How about I hold off on this until after the 1.0, and then if you still
> need it then, we can talk about adding it?
>
>> I don't like wrapper scripts, personally I'd like to loose them all
>> where/if I could from our puppies, but I'm just one builder.
>>
>> With Rob being flexible and  properly controlling what was happening
>> inside toybox, I thought there may be a way to do it simply/easily for
>> all inbuilt commands for toybox.
>
> We can, but I'd really rather get feature requests at least while the
> roadmap is still in flux on the way to 1.0.
>
>> And as a side, it also may cause other
>> linux's to consider having toybox in their set even for just this one
>> feature.
>>
>> I did say when I started this discussion, that i'd prefer not to add to
>> the default set. I had hoped it could be handled internally and simply
>> for all toybox commands. I also said I'm not a coder! and so was putting
>> up what I considered a possibly useful thought path, not a solution,
>> which is why I labeled it ?from left field.
>
> I already have the which -a plumbing factored out, and I could do a
> simple stat of each which -a entry for toys.which->name and for
> /proc/self/exe and run the first one (if any) that doesn't match, and
> fall back to the old "error message" behavior if there isn't a command
> to hand off to. This isn't _hard_.
>
> However, toybox is intended to be a fully functional implementation of
> basic linux commands. It's not intended to treat other implementations
> as somehow superior: if you want gnu sed, switch off toybox's sed and
> install the gnu version. This is why menuconfig exists. If you want to
> use gnu sed but toybox is missing a feature, _tell_me_. (I can't
> guarantee I'll add it, but this is something I do in fact want to know.)
>
> You can even have a "/usr/interpose/bin" directory with symlinks to gnu
> or bsd or toolbox or busybox versions of commands, and then have some
> processes run with that at the start of their $PATH (before toybox) and
> other commands not run like that. You don't actually _need_ toybox to
> specially support this...
>
>> I also intend to add toybox into my T2 V9.0 (trunk) Puppy Linux called
>> Puppy T290 as I expand it through alpha's, as I have always since first
>> coming across it through aboriginal, consider it a magnificant and
>> worthwhile addition to linux, (no swollen heads please).
>
> Eh, I started that way. (I balanced egomania with impostor syndrome to
> come to the conclusion EVERYBODY sucks at this, so I might as well take
> a stab if nobody else is getting around to the stuff I want to see
> happen. People don't steal my ideas enough, so I wind up having to do it
> myself.)
>
>> And greetings Isaac, you are right, we Puppians have had quite a
>> 'robust' discussion over the years, since BarryK started Puppy Linux,
>> about the use of full and partial command sets using wrappers, it's
>> still not agreed to in either way, and I suspect it will never be.
>
> It's actually more complicated than that. Toybox mostly doesn't do the
> "busybox find has 22 different config symbols" nonsense, but we do have
> the occasional thing like CP_MORE or DF_PEDANTIC. So you're sort of
> implying it might want to fall back to a more fully configured toybox
> version as a second entry in the $PATH.
>
> I'd love to address the problem. This does not seem like it's actually
> fixing anything, it seems like an excuse NOT to fix a case where toybox
> doesn't do something users need it to do.
>
> Rob
>
>

Um,

I didn't expect it to appear now, just something to consider for the 
future, but I thought that if I didn't mentioned it now, there was a 
possability it might have been impossible to implement later due to 
coding changes. After 1.0 is fine by me, I actually hadn't realized you 
were that close so congradulations, your the coder after all.

The idea I had, I think is along the lines, that Toybox "out-of-the-box" 
(escuse the pun) should be something that works for most users at most 
times as is, with the fallback to a full command only when it's 
(very-seldomly) needed. Thus having full commands for everything should 
become the run exception and not the norm. Something like what happened 
when busybox first appeared and took over some of the large command 
sets. I don't want my everyday toybox 'having all the possible switches 
for command' senario, it would become humungous (good word that) and 
unworkable. I hadn't thought about a second expanded toybox though, and 
that brings the thought that maybe it could be compressed inside the 
first (not opened by default) and expanded into ram only when required.

And, yes, I like your last comment Rob, paraphrasing slightly, 'it's to 
add it when it's useful to do so for many users and not where it is only 
used by few, as other methods are available already for the result wanted'.

jon

 1414006476.0