>Would it be acceptable to you and them to put the binaries in /bin/s6
>and then very early in the boot add /bin/s6 to the path? This isn't a
>lot different from what djb did with /command, except it's not off the
>root, which everyone seems to hate.
s6 binaries aren't a problem for Debian; but apparently, execline
binaries are. They're doing exactly that: they're storing execline
binaries under /usr/lib/execline - except they're not putting that
directory in the default PATH, they're only adding it to PATH when
execlineb is invoked. Which breaks some s6 commands in older s6
versions,
and breaks s6-rc commands (any version), because those assume that
execline binaries can be found in their PATH, and don't call execlineb.
It's completely acceptable to me to put binaries in a separate
directory.
But said separate directory *needs* to be in the default PATH. If it is
not, it means that those binaries are considered second-class citizens,
and that is *not* acceptable - and even more importantly, it breaks
things.
>As a guy who has both daemontools and s6 installed on the same box, I
>thank you from the bottom of my heart for:
>
>1) Prepending s6- to each command so they don't clash with djb's
>2) Except for the s6-, naming them the same as djb's so I have less to
> remember.
Yes, there are a good number of people, me included, who prefer that
naming scheme. However, Jan's UX return is valid, and if I want to make
s6 adoption as easy as possible, it needs to be taken into account too.
>A simple change change I think would do it is to change the
>documentation to imply that, for the *user*, execlineb is a way to get
>just a little extra whatever. Currently, when I read it, I thought I'd
>be missing a lot by using /bin/sh.
I think it's already the case, but I'll make a pass on the documentation
to make it abundantly clear.
>Does the *user* need to code execline scripts, or is it just
>something the program does? If the former, then make a point that one
>doesn't need to use execline for s6-rc to be a very powerful startup
>system.
1. execline is used *internally* by s6-rc, in autogenerated scripts.
The
user doesn't have to know anything about it.
2. source oneshot up/down scripts are parsed by execlineb, so this is a
place where users interact with it. However, the interaction can be made
pretty minimal if the up/down script just calls a shell script stored
somewhere else (typically /etc/init.d), which is common, and generally
good, practice.
For instance, the "source/network-interfaces/up" script could simply
contain:
/etc/init.d/network start
and that's it. Technically, this is an execline script, made of two
words,
but nobody needs to know that; and the complex logic of the script can
be
implemented in the /etc/init.d/network program, which can be written in
any language. Even in a compiled language, if you're a masochist.
Advanced users can write more complex logic in the
source/network-interfaces/up script itself, using execline binaries for
control flow, etc. But it's by no means essential. For all intents and
purposes, that script is just a small command line that execs into
another
script, hosted wherever you want, written in whatever language you want.
So I'd say the necessary interaction between s6-rc users and execline is
really tiny.
>If anybody would make an execline tutorial, that would help a lot. For
>a guy like me who only does procedural programming (C, C++, Pascal,
>Perl, Python, Ruby, Lua, etc), execline is difficult to understand.
Well, for one, the execline documentation is bad (it was my first real
attempt at writing software documentation, and it shows), so revamping
it
would probably help a lot. And second, there *are* execline tutorials
online, you just haven't looked.
--
Laurent
Received on Mon Dec 02 2019 - 21:32:32 UTC