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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
