busybox with single applet enabled

Sergey Naumov sknaumov at gmail.com
Fri May 20 03:44:06 UTC 2011


> busybox is about small size. If binary contains exactly one applet,
> why it should include any code to check its name?

Of course it shouldn't, but may be it is possible to issue a warning
at compilation stage, smth like "busybox was built as single applet.
Do not call it as 'busybox applet_name'."

last_fancy patch:
In expectation of a question, I want to answer that of course I know,
that all filtering can be done by grep, sed and so on, but if you
don't want to touch old code that uses full-blown last or you use user
interface where user can specify exactly one command... I deal with
such a project, so I send a patch just in hope it can be useful for
smbd, not because I insist on incorporating it.

adduser/addgroup:
While working on adduser -C, I found a todo about invocation of
addgroup from adduser with -g flag and incompatibility with desktop
adduser. I have tried to solve it, but discovered that we can
unambiguously determine what kind of program we execute (applet or
desktop program) only if FEATURE_PREFER_APPLETS is enabled. If it is
disabled, then we can't detect type of program by finding executable -
it could be just applet wrapper. May be the easiest way to solve this
issue is to enable long options in addgroup by menuconfig
infrastructure if  FEATURE_PREFER_APPLETS is not selected, or anyway
try to use applet first regardless FEATURE_PREFER_APPLETS disabled.

Also without FEATURE_PREFER_APPLETS we will not call applet (if it was
not "installed" - no symlink or wrapper script) even if we didn't find
a desktop program, because in spawn_and_wait we call spawn, and there
we call BB_EXECVP version without applet searching. It is mostly about
testing, because on embedded system applet will be "installed", but is
it desired behavior or bug?

Sergey Naumov.


More information about the busybox mailing list