7 ms·

I wouldn't say the init scripts on OpenBSD are complex: # cat smtpd #!/bin/sh # # $OpenBSD: smtpd,v 1.4 2012/10/26 06:51:59 ajacoutot Exp $ daemon="/usr/sbin

by pppp 11y ago

I wouldn't say the init scripts on OpenBSD are complex: # cat smtpd #!/bin/sh # # $OpenBSD: smtpd,v 1.4 2012/10/26 06:51:59 ajacoutot Exp $ daemon="/usr/sbin/smtpd" . /etc/rc.d/rc.subr pexp="smtpd: \[priv\]" rc_reload=NO rc_cmd $1

EmanueleAina 11y ago
Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either. One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.
- falcolas 11y ago
  That's not a DSL, that's a shell script. As for what `pexp="..."` does - it's just setting the pexp variable. If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script. No DSL knowledge required, at all. Just shell knowledge, and the willingness to look at sourced shell scripts.
  - rjcz 11y ago
    > If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script. Ouch... Shell (or Bourne Shell to be exact), not bash. Bash is a type of Shell and it's not* even available (thank goodness) on either of the BSDs in their base system (only as a port and/or package). On OpenBSD, the actual command line interpreter is actually Korn, not the Bourne, Shell.
  - EmanueleAina 11y ago
    I mean, I know that it sets a variable, I can't even guess what are the effect of setting that variable. And "look at the source" is a sad answer, no matter if the source is a shell script or C program. The point is that with your example you need domain knowledge, knowing bash is not enough: what does the pexp assignment do, what rc_reload=NO means, should flags be specified in the daemon variable or that's meant to only contain the binary, does that path be full or it takes in consideration a standard PATH? And now you got two things to know: the bash (or even strictly posix sh) language (which, admittedly, isn't the best one in the world) and the domain specific functions/variables. This isn't much different than with systemd: the language is much more simple and far less surprising being INI-like (the same as .desktop files), and it's basically just setting a list of rather well documented variables.
- ben_bai 11y ago
  man rc.subr pexp A regular expression to be passed to pgrep(1) in order to find the desired process or to be passed to pkill(1) to stop it. By default this variable contains the daemon and daemon_flags variables. To override the default value, an rc.d script has to redefine this variable after sourcing rc.subr.
  - digi_owl 11y ago
    That you can import shell scripts into shell scripts is one of those things that catch many off guard when first encountered. But when grok-ed, really demonstrate how far shell script can go.
  - EmanueleAina 11y ago
    Thanks, that wasn't the point. What I was trying to say is that if you use those helpers you're looking up stuff in a man page anyway, so knowing shell scripting isn't enough any longer. My personal opinion is that having a simple, INI-derived language is better than keeping the weirdness of the shell language just to assign a couple of variables (and you can still launch shell scripts from units anyway).
- yellowapple 11y ago
  > But at that point you have a DSL which is no longer obvious when one only knows about shell scripting At which point you can run `man rc.subr` and be enlightened :)
  - EmanueleAina 11y ago
    Yep, my point is that knowing shell scripting alone is no longer enough and it's not different than running `man systemd.service`, only that you're keeping the weirdness of the shell language just to set a couple of variables.
    - yellowapple 11y ago
      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 to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts. Even if you decide that shell scripts are the spawn of the devil and ought to be burned on the stake (which, honestly, isn't all that unreasonable of a decision), it's quite possible to implement the same functionality using Ruby or Python or Perl or C or Go or Rust or Erlang or Lisp or PHP or COBOL or MIPS assembly or whatever-the-hell-else you feel like writing init "scripts" in (with some exceptions; FreeBSD and NetBSD, for example, apparently launch initscripts with 'sh' instead of following the OpenBSD and GNU/Linux approach of calling initscripts as executables). The biggest point, though, is that because of this, if your only goal is to have terse daemon configuration with a minimum of boilerplate, you can have that without having to learn at minimum two languages (one to write your initscripts and one to do all the rest of your day-to-day administration tasks). You just learn shell and you're done. With systemd, you still have to learn shell scripting for even systemd-related tasks (let alone non-systemd-related tasks) plus a new DSL that looks like INI but isn't quite INI. I guess that's tolerable coming from, say, the Windows world (where you're learning DOS batch language and PowerShell and VBScript and INI and Lord-knows-what-else), but that's double what a seasoned Unix admin requires in a non-systemd environment, which is pretty significant.

by pppp 11y ago

EmanueleAina 11y ago

Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either. One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.

falcolas 11y ago
That's not a DSL, that's a shell script. As for what `pexp="..."` does - it's just setting the pexp variable. If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script. No DSL knowledge required, at all. Just shell knowledge, and the willingness to look at sourced shell scripts.
- rjcz 11y ago
  > If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script. Ouch... Shell (or Bourne Shell to be exact), not bash. Bash is a type of Shell and it's not* even available (thank goodness) on either of the BSDs in their base system (only as a port and/or package). On OpenBSD, the actual command line interpreter is actually Korn, not the Bourne, Shell.
- EmanueleAina 11y ago
  I mean, I know that it sets a variable, I can't even guess what are the effect of setting that variable. And "look at the source" is a sad answer, no matter if the source is a shell script or C program. The point is that with your example you need domain knowledge, knowing bash is not enough: what does the pexp assignment do, what rc_reload=NO means, should flags be specified in the daemon variable or that's meant to only contain the binary, does that path be full or it takes in consideration a standard PATH? And now you got two things to know: the bash (or even strictly posix sh) language (which, admittedly, isn't the best one in the world) and the domain specific functions/variables. This isn't much different than with systemd: the language is much more simple and far less surprising being INI-like (the same as .desktop files), and it's basically just setting a list of rather well documented variables.
ben_bai 11y ago
man rc.subr pexp A regular expression to be passed to pgrep(1) in order to find the desired process or to be passed to pkill(1) to stop it. By default this variable contains the daemon and daemon_flags variables. To override the default value, an rc.d script has to redefine this variable after sourcing rc.subr.
- digi_owl 11y ago
  That you can import shell scripts into shell scripts is one of those things that catch many off guard when first encountered. But when grok-ed, really demonstrate how far shell script can go.
- EmanueleAina 11y ago
  Thanks, that wasn't the point. What I was trying to say is that if you use those helpers you're looking up stuff in a man page anyway, so knowing shell scripting isn't enough any longer. My personal opinion is that having a simple, INI-derived language is better than keeping the weirdness of the shell language just to assign a couple of variables (and you can still launch shell scripts from units anyway).
yellowapple 11y ago
> But at that point you have a DSL which is no longer obvious when one only knows about shell scripting At which point you can run `man rc.subr` and be enlightened :)
- EmanueleAina 11y ago
  Yep, my point is that knowing shell scripting alone is no longer enough and it's not different than running `man systemd.service`, only that you're keeping the weirdness of the shell language just to set a couple of variables.
  - yellowapple 11y ago
    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 to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts. Even if you decide that shell scripts are the spawn of the devil and ought to be burned on the stake (which, honestly, isn't all that unreasonable of a decision), it's quite possible to implement the same functionality using Ruby or Python or Perl or C or Go or Rust or Erlang or Lisp or PHP or COBOL or MIPS assembly or whatever-the-hell-else you feel like writing init "scripts" in (with some exceptions; FreeBSD and NetBSD, for example, apparently launch initscripts with 'sh' instead of following the OpenBSD and GNU/Linux approach of calling initscripts as executables). The biggest point, though, is that because of this, if your only goal is to have terse daemon configuration with a minimum of boilerplate, you can have that without having to learn at minimum two languages (one to write your initscripts and one to do all the rest of your day-to-day administration tasks). You just learn shell and you're done. With systemd, you still have to learn shell scripting for even systemd-related tasks (let alone non-systemd-related tasks) plus a new DSL that looks like INI but isn't quite INI. I guess that's tolerable coming from, say, the Windows world (where you're learning DOS batch language and PowerShell and VBScript and INI and Lord-knows-what-else), but that's double what a seasoned Unix admin requires in a non-systemd environment, which is pretty significant.