Simon Hobson <linux@???> writes:
> Rainer Weikusat <rainerweikusat@???> wrote:
>>> - Some headers to tell utilities what runlevels the service should run
>>> at, and dependencies.
>>
>> That's a LSB invention. It's a grotesque travesty as it uses 'magic
>> comments' to embed a declarative mini programming language in an init
>> script which is only ever used when modifying the runlevel
>> configuration. Comments are supposed to be used for relatively short,
>> free-style documentation embedded in code, not for interpretation by
>> programs.
>
> Presumably you have a suitable alternative, that's "backwards
> compatible", admin accessible, and makes sense to others?

Since nobody ever paid me to design one and I don't need something like
this for accomplishing anything I do get paid to accomplish, obviously
no. But I don't quite understand how arbitrary facts from my personal
history relate to 'language design'.

>>> - A ". include" to pull in some standard functions - makes sense, no
>>> point everyone building their own wheel.
>>
>> Insofar these functions are generally useful, ie, not just carp like
>> "print a RED message", they ought to become proper programs which could
>> then be used in init scripts or elsewhere.
>
> Well since (I suspect) most of them don't have much (if any)
> applicability outside of init scripts, I'd say a library of common
> functions as an include makes sense.

"Not applicable outside of init scripts" (and this only conjectured)
neither means "should be implemented using the bourne-shell language"
nor "should reside in a file with shell language function definitions to
be sourced at runtime". Eg, the start-stop-daemon program is not a shell
function despite it's not supposed to be used outside of init scripts.

> Do you also object to libraries of common functions in other
> languages?

Every programming language I'm using has surely a great many 'libraries
of common functions' to whose use I object (usually by not using
them). But see above regarding 'random facts about me'. Also, the set of
executable commands can be regarded as 'library of common functions for
use in shell scripts'/

>>> - Check for, and if found, load a config file - eg
>>> /etc/default/${service}
>>
>> TOCTOU race. Running
>>
>> [ -r /etc/default/sendmail ] && . /etc/default/sendmail
>>
>> doesn't mean /etc/default/sendmail will still be available when the
>> source command is executed. Since the shell is (for the sendmail init
>> script) running without -e at this point, the test can just be dropped.
>
> Strictly speaking, yes you are correct. However, unless there is
> something seriously wrong with the system then /etc/default/${program}
> isn't going to be appearing or disappearing at this time. However, as
> it is an optional file for many programs, it does (IMO) make sense to
> handle whether it is there or not, rather than "just fail" with an
> ugly message.

It's usually not optional for packages using one (it's supposed to
contain nothing but customizable parameters for an init script to make
it easier to customize these without having to deal with code merging
upon init script updates). It's supposed to be possible to delete these
files but usually, one would leave them in place an just comment out
whatever is not supposed to be made available.

If someone deleted a /etc/default file, a script trying to use that
printing a '/etc/default/xyz not found' before continuing seems
perfectly acceptable to me.

[...]

> As a thought, have you submitted a "fixed" Sendmail script to the
> Sendmail project ?

My opinion on what such a script should do and that of the Debian
sendmail maintainer are "not compatible" in this regard. If I considered
this worth the effort, I'd replace the script for systems I control,
however, I don't mind the code implementing the features he considers
sensible[*]. But I do mind people running around crying "sysvinit is the
evil incarnate!" and then point at a few hundreds of lines of shell
script code someone developed completely indepdendently of the init
system because he considered that a good thing.

[*] /etc/mail/sendmail.conf has a HANDS_OFF variable which exists
because I complained about the package overwriting my sendmail
configuration and that's good enough for me