[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