[BusyBox] overriding builtins

Erik Andersen andersen at lineo.com
Fri Nov 17 00:24:32 UTC 2000


On Thu Nov 09, 2000 at 12:16:28PM -0800, Larry Doolittle wrote:
> I get unexpected behavior trying to override "builtin"
> sh functions.  If I give an explicit path, I can
> override the true builtins, both forking and non-forking.
> Applets, like insmod, can not be overridden.
> 
> I like the BB_FEATURE_SH_STANDALONE_SHELL, I think
> it saves memory and CPU cycles.  But in this case,
> it really gets in the way.
> 
> The actual test (version 0.47, and 0.48pre from last
> week) is on line 1208 of sh.c:
>   strcmp(get_last_path_component(newJob->progs[i].argv[0]), a->name) == 0
> where a iterates through the BB_applet's (and not the
> builtins).
> 
> What if that test compared the full argv[0] to the
> applet's assumed pathname, as determined by combining
> install_dir[a->location] with a->name?  This would
> require hacking the #ifdef around the install_dir
> declaration in busybox.c.
> 
> Or, the code could double check that a builtin is
> appropriate, by doing an lstat()/readlink() on
> newJob->progs[i].argv[0], and see if it is a symbolic
> link to busybox.
> 
> For the case where a "/" exists in argv[0], it might
> even be interesting to stat() argv[0], and compare it
> with our own inode, as the _only_ test.  It might be
> an interesting exercise to portably and reliably find
> our own inode.
> 
> I have only looked at the possibilities, not changed
> or tested anything.  If I get some feedback as to which
> way makes sense to a larger audience (and a patch would
> therefore be accepted), I will proceed.

I'd be ok with having it first stat for an external app and use that if it
exists, otherwise default to the builtin.  I think that would be nice -- nicer
then something like having to prepend a "-" or some-such to get the builtin..

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--





More information about the busybox mailing list