| Embedded Shell Scripts in BusyBox | |
| ================================= | |
| BusyBox allows applets to be implemented as shell scripts. Since | |
| this obviously requires a shell to interpret the scripts the feature | |
| depends on having a shell built into the binary. Either ash or hush | |
| will do. If both are present ash will be used. Support for embedded | |
| scripts also has to be enabled. | |
| It's unlikely that your applet will be implemented as a pure shell | |
| script: it will probably need some external commands. If these are | |
| to be provided by BusyBox you'll need to ensure they're enabled too. | |
| There are two ways to include scripts in BusyBox: the quick-and-dirty | |
| custom script and the full-featured scripted applet. | |
| Custom Scripts | |
| -------------- | |
| When embedded script support is enabled the BusyBox build process | |
| assumes that any files in the directory 'embed' at the top level of | |
| the source tree are scripts to be embedded. | |
| The embed directory isn't present in the BusyBox source tree and | |
| BusyBox itself will never put anything there: it's entirely for the | |
| use of third parties. | |
| Adding a custom script is as simple as running the following sequence | |
| of commands in the BusyBox source directory: | |
| mkdir embed | |
| echo 'echo foo' >embed/foo | |
| make defconfig | |
| make | |
| The resulting binary includes the new applet foo! | |
| Custom scripts have limited opportunities for configuration: the only | |
| control developers have is to put them in the embed directory, or not. | |
| Everything else takes default values. For more control you need the | |
| additional features provided by scripted applets. | |
| Scripted Applets | |
| ---------------- | |
| Suppose we want to make a shell script version of the sample applet | |
| from the New Applet HOWTO. First we'd have to write a script (vaguely) | |
| equivalent to the C code: | |
| return $(($RANDOM%256)) | |
| This should be placed in the file applets_sh/mu in the source tree. | |
| Next we need the configuration data. This is very similar to the example | |
| code for the native applet: | |
| //config:config MU | |
| //config: bool "MU" | |
| //config: default y | |
| //config: help | |
| //config: Returns an indeterminate value. | |
| //applet:IF_MU(APPLET_SCRIPTED(mu, scripted, BB_DIR_USR_BIN, BB_SUID_DROP, mu)) | |
| //usage:#define mu_trivial_usage | |
| //usage: "[-abcde] FILE..." | |
| //usage:#define mu_full_usage | |
| //usage: "Returns an indeterminate value\n" | |
| //usage: "\n -a First function" | |
| //usage: "\n -b Second function" | |
| The only difference is that the applet is specified as being of type | |
| APPLET_SCRIPTED. It would also be useful to include details of any | |
| dependencies the script has. No external commands are used by our mu | |
| script, but it does depend on optional shell features. We can ensure | |
| these are selected by adding this to the configuration: | |
| //config:config MU_DEPENDENCIES | |
| //config: bool "Enable dependencies for mu" | |
| //config: default y | |
| //config: depends on MU | |
| //config: select ASH_RANDOM_SUPPORT | |
| //config: select FEATURE_SH_MATH | |
| //config: help | |
| //config: mu is implemented as a shell script. It requires support | |
| //config: for $RANDOM and arithmetic. | |
| The configuration data should be placed in a C file in an appropriate | |
| subdirectory. There isn't any C code, though! In this case the file | |
| could be miscutils/mu.c. | |
| Scripted applets are just as configurable as applets written in C. | |
| They can be enabled or disabled using the configuration menu; their | |
| install directory can be specified and their usage messages are stored | |
| along with those of all other applets. | |
| Additional Notes | |
| ---------------- | |
| The source for embedded scripts can be displayed by running: | |
| busybox --show SCRIPT | |
| This can be disabled by turning off FEATURE_SHOW_SCRIPT in the | |
| configuration, though it won't prevent a determined user from | |
| extracting the source code. | |
| It can be argued that embedded scripts are linked into the BusyBox | |
| binary and are therefore not subject to the 'mere aggregation' | |
| exception in the GPL. If this is the case embedded scripts should | |
| have a licence compatible with BusyBox's GPL v2-only licence. |