>I am trying to determine whether is feasible and sane for me to try to
>port
>Slackware's init scripts that initialize such things as filesystems,
>kernel
>modules, network interfaces, etc. I would be trying to write these in
>execline as oneshot services to be started by s6-rc at the very
>beginning
>of the dependency tree.
It's certainly feasible. Whether it is desirable, or sane, is another
question entirely. :)
First, note that you don't have to convert a script to execline in
order
to use it as a s6-rc oneshot. You can, for instance, have a sysvrc-style
shell script in /etc/init.d/foobar, and build your s6-rc foobar service
with "/etc/init.d/foobar start" in foobar/up and "/etc/init.d/foobar
stop"
in foobar/down.
Or you can even directly write: /bin/sh -c "my shell script"
in an up or down file for s6-rc, if you're mastering the execline
quoting
enough to write a whole shell script execline-quoted this way.
Second, be aware that using execline is actually beneficial over using
a shell in very simple scripts, especially scripts involving large
amounts of chain loading - such as s6 run scripts, for instance; but for
more complex scripts with control structures or advanced features,
it's very possible that you gain nothing. So, conversion of a shell
script to execline is an excellent exercise in learning execline, but
past a certain point it doesn't necessarily have intrinsic value. RC
scripts are kind of on the edge - some of them can be easily translated
to execline for speed gains, and for others it's just not worth it.
Third, converting rc scripts from a distribution to a s6-rc service
database is currently the *most valuable contribution* you can do for
s6-rc. I'm not joking: what s6 and s6-rc need right now is adoption
by mainstream distribution, and the limiting factor is clearly the
conversion from sysvrc or OpenRC scripts to the s6-rc source format.
So if you're going to attempt this for Slackware, you have my whole
support, and my thanks; but this is a large task, and does not need
extra porting work piled onto it. If you can do that, it will be a
big, and useful, achievement, even if the scripts are still shell
scripts.
So, my overall advice is to just not try translating the rc scripts
to execline - at least as a first step - and focus on the conversion to
the s6-rc source format instead. If, during that conversion, you notice
certain simple scripts that would clearly benefit from being rewritten
in execline instead of shell, then why not - but I definitely wouldn't
make this a primary goal.
Now to answer your question:
>The problem I am anticipating is that with execline, it seems as though
>I
>will not have access to any of the shell environment variables that
>Slackware uses heavily for its rc scripts. Since my (admittedly insane)
>goal is to provide a drop-in replacement for all Slackware rc scripts,
>I
>would need some way to replicate these variables or keep them intact.
Indeed, execline provides no shell variables since there is no resident
interpreter. The idiomatic way of reading information for an execline
script is to store that information in an envdir, and read it at the
start of the script via s6-envdir, which will put the information into
environment variables:
http://skarnet.org/software/s6/s6-envdir.html
If you cannot convert the information to an envdir format and are stuck
with a series of "key=value" instructions read from a shell, you can
simply write a small shell script, "read-env", that reads those
instructions, exports all the relevant keys to the environment, then
execs into the rest of its command line. read-env then becomes a
command that behaves like s6-envdir, but for shell-format files; and
you can integrate this command in your execline scripts.
If you need support for the Slackware rc scripts conversion, I
recommend
you join #s6 on Freenode - we are *very* interested in that work and
you'll likely always find someone who's ready to assist you. (Of course,
the mailing-lists are good too!)
--
Laurent
Received on Fri May 19 2017 - 19:53:12 UTC