Earlier quoted context omitted.
Except that rc.subr is shell scripting alone. It's literally a shell script that gets sourced into another shell script (in this case, your initscript), which is - again - ordinary shell behavior. Yeah, you have to learn a couple of shell functions and variables, but that's not really that big of a deal for someone with even cursory knowledge of shell scripting. The bigger point, though, is that if your only goal is…
> Except that rc.subr is shell scripting alone. Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it. My point is that either one has to get some domain-specific knowledge or they have to reverse engineer some code. Given that I believe that the second one is a bad choice (people will rely on the implementation r…
rc.subr also comes with proper documentation, in the form of the rc.subr manpage, which comprehensively documents its behavior.
Barring that, you're delusional if you think that C is anywhere near as readable as shell in this sort of context.
> My point is that either one has to get some domain-specific knowledge
Arguably less of it in the case of rc.subr, since said knowledge is already part of basic shell scripting knowledge.
> Literally nobody ever claimed that systemd "only goal" is to have terse daemon configuration.
Nor did I. That doesn't change the fact that "OMG initscripts are so verbose with so much boilerplate; my unit files are so much better" is a commonly-cited reason for people to prefer systemd over other init systems, never mind that said reasoning is plainly false.