[BusyBox] overriding builtins

[Larry Doolittle]

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.

       - Larry Doolittle   <LRDoolittle at lbl.gov>