Kang-Che Sung wrote:
>Let no script applets individually configurable in menuconfig. Let users
>resolve the dependencies of whatever they put in applets_sh.
My view is that if script applets are provided as part of BusyBox they
should have all the features of native applets, including the usual
Aaro Koskinen wrote:
>Not sure if either of these are good.
OK, we could use the old 'add another level of indirection' trick:
config NOLOGIN_DEPENDENCIES
bool "Dependencies for nologin"
default y
depends on NOLOGIN
select CAT
select ECHO
select SLEEP
Can we do this instead:
Let no script applets individually configurable in menuconfig. Let users
resolve the dependencies of whatever they put in applets_sh.
If user needs to temporarily not embed a particular applet in that folder,
then we can provide a "DISABLE" file that specifies which
On Tue, Nov 06, 2018 at 08:36:11PM +, Ron Yorston wrote:
> For the rest I suppose there are a couple of ways to look at it. The
> dependencies could be specified explicitly:
>
>depends on ASH_EMBEDDED_SCRIPTS && (ECHO || ASH_ECHO) && CAT && SLEEP
>
> Though this means that scripted
Aaro Koskinen wrote:
>Should users be told they are enabling a scripted applet? E.g. in this
>case they should also enable some other busybox applets to make it work
>(like "cat")... I wonder how it's going to work in practice.
Because of the 'depends on ASH_EMBEDDED_SCRIPTS' we known that we
Now that scripts can be embedded in the BusyBox binary it's possible
to implement applets as scripts.
Such scripts should be placed in the 'applets_sh' directory. A stub
C program should be written to provide the usual applet configuration
details and placed in a suitable subsystem directory.
