On Tue, Oct 21, 2014 at 09:06:03PM +1100, scsijon wrote: > > On 10/21/2014 02:52 PM, Isaac Dunham wrote: > >On Mon, Oct 20, 2014 at 11:47:32AM -0500, Rob Landley wrote: > >>On 10/20/14 01:50, Isaac Dunham wrote: > >>>On Mon, Oct 20, 2014 at 01:17:44PM +1100, scsijon wrote: > >>>>I was wondering if toybox 'could / would be able to' have an auto tool > >>>>built > >>>>into it. I'm not a coder, so can't do it, but.... > >>>> > >>>>Along the line of: > >>>>-- > >>>>If toybox had the command 'siliswap' built into it, but it's inbuilt > >>>>siliswap was a subset of the full 'siliswap' command and it's complete set > >>>>of switches, as for most people and programs it doesn't need the others. > >>>> > >>>>If at a later stage, the user needs to install the full 'siliswap' package > >>>>because they need to use switches that are not built into toybox's > >>>>'siliswap' then toybox's 'siliswap' knows to pass the request onto the > >>>>full > >>>>siliswap instead of dealing with it itself. > >>>>-- > >>>>Not sure if it could be added without a shell file though and i'd prefer > >>>>not > >>>>to add to the default set. ?or could these be created automatically when > >>>>toybox is first run, against all inbuilt packages, or manually with a > >>>>toybox > >>>>-cfg command). > >>>> > >>>>And of course, toybox doesn't have or needs siliswap (it's a very old IBM > >>>>Mainframe silo interface command), i'm not sure it is even used anymore. > >>> > >>> > >>>1. Rob keeps talking about simplicity...this doesn't sound very simple. > >>>It also doesn't sound small--which defeats the point of implementing a > >>>subset. > >> > >>A lot of simplicity is how you look at the problem. :) > >> > >>In this case, xexec() tries the builtin version, then falls back to > >>exec. If you add a path to your command, it never tries the builtin > >>version. So "/bin/echo" will always try to exec. That's the current > >>behavior. > > > >>When execing, the symlinks can be replaced after the fact. Even if > >>"echo" is built into toybox, if /bin/echo isn't a symlink pointing to > >>toybox then running it will run something else. You can delete the old > >>symlink and replace it with whatever you want to add to the system. > >>(This flexibility is intentional, and again is the current behavior.) > > > >I understood the request somewhat differently, partly due to some > >discussions on the Puppy Linux forums (where scsijon is also a member). > >(I may have misunderstood, though.) > > > >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...). 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).
Does "always search $PATH" work well enough? The theory here is that you would install toybox with links, and the full command would replace a link to toybox. > however, for now, > regards to all > jon Thanks, Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
