1. Write a stage-1 init script in standard Linux Bash shell scripting. Because Bash is the stereotypical universal Linux shell on most distributions, we felt that it's usage in the scripting process would aid and ease s6 into the system faster and cleaner. However, we are not above utilizing scripting using execline if necessary as a learning tool, but our goal is to use standard Bash.
My point is that there are a few shells out there, and people may want to use something else than bash. (ash, dash, zsh, you name it, someone swears by it.) So please use /bin/sh and avoid bashisms to remain portable (if that means anything for a stage 1 init). The only place where you will need a bit more oomph than /bin/sh provides is to open a fifo for writing when there's no reader yet. (To redirect /sbin/init's stdout and stderr to the fifo that will be read by the catch-all logger, but the logger isn't up yet since it will be started by s6-svscan.) That shouldn't be a problem though: you have execline installed and you can use redirfd in a shell script. You will just have to write something like "exec redirfd -wnb 1 fifo sh -c 'rest of script'". Chain loading works with the shell too, it's just cumbersome (and a bit slower) when you need to execute into another shell.
2. As far as service scripts are concerned, we may use either execline or bash scripting depending on which moved things along faster.
/bin/sh is perfectly fine as long as you remember to exec the long-running process in the end to avoid keeping a dangling shell and sending signals to the wrong process. The main reason I use execline for run scripts is that execline is best suited for pure chain loading, and run scripts mostly involve process state changes (fd redirections, environment setting, resource limits setting, etc.) followed by an exec, and those are best performed by chain loading: both runit and s6 provide process state change programs for such use. Chain loading also makes it easy, for instance, to insert a "strace -vf" at any point in your run script for debugging purposes. -- Laurent
