I've looked to all those things. But to me, there are a lot of small details that isn't said explicitly.
Code:
start_precmd="${name}_prestart"5
stop_postcmd="echo Bye-bye"6
extra_commands="reload plugh xyzzy"7
plugh_cmd="mumbled_plugh"8
xyzzy_cmd="echo 'Nothing happens.'"
mumbled_prestart()
{
if checkyesno mumbled_smart; then9
rc_flags="-o smart ${rc_flags}"10
fi
case "$mumbled_mode" in
foo)
rc_flags="-frotz ${rc_flags}"
;;
bar)
rc_flags="-baz ${rc_flags}"
;;
*)
warn "Invalid value for mumbled_mode"11
return 112
;;
esac
run_rc_command xyzzy13
return 0
}
mumbled_plugh()14
{
echo 'A hollow voice says "plugh".'
}
in the example of the handbook, xyzzy and plugh are use as arguments I presume? But the name of the variable is xyzzy_cmd not only xyzzy. So does the rc know that every _something is not in the name of the variable but is the type of the parameter?
Or is it that note from the rc.subr article :
Note: ()rc.subr(8). You should additionally set command_interpreter to let
rc.subr(8) know the actual name of the process if $command is a script.
For each rc.d script, there is an optional
rc.conf(5) variable that takes precedence over command. Its name is constructed as follows: ${name}_program, where name is the mandatory variable we discussed
earlier. E.g., in this case it will be mumbled_program. It is
rc.subr(8) that arranges ${name}_program to override command.
Of course,
sh(1) will permit you to set ${name}_program from
rc.conf(5) or the script itself even if command is unset. In that case, the special properties of ${name}_program are lost, and it becomes an ordinary variable your script can use for its own purposes. However, the sole use of ${name}_program is discouraged because using it together with command became an idiom of rc.d scripting.() manual page" href="https://man.freebsd.org/cgi/man.cgi?query=
Some programs are in fact executable scripts. The system runs such a script by starting its interpreter and passing the name of the script to it as a command-line argument. This is reflected in the list of processes, which can confuse
rc.subr(8). You should additionally set command_interpreter to let
rc.subr(8) know the actual name of the process if $command is a script.
For each rc.d script, there is an optional
rc.conf(5) variable that takes precedence over command. Its name is constructed as follows: ${name}_program, where name is the mandatory variable we discussed
earlier. E.g., in this case it will be mumbled_program. It is
rc.subr(8) that arranges ${name}_program to override command.
Of course,
sh(1) will permit you to set ${name}_program from
rc.conf(5) or the script itself even if command is unset. In that case, the special properties of ${name}_program are lost, and it becomes an ordinary variable your script can use for its own purposes. However, the sole use of ${name}_program is discouraged because using it together with command became an idiom of rc.d scripting.&sektion=&manpath=freebsd-release-ports">
Some programs are in fact executable scripts. The system runs such a script by starting its interpreter and passing the name of the script to it as a command-line argument. This is reflected in the list of processes, which can confuse
rc.subr(8). You should additionally set command_interpreter to let
rc.subr(8) know the actual name of the process if $command is a script.
For each rc.d script, there is an optional
rc.conf(5) variable that takes precedence over command. Its name is constructed as follows: ${name}_program, where name is the mandatory variable we discussed
earlier. E.g., in this case it will be mumbled_program. It is
rc.subr(8) that arranges ${name}_program to override command.
Of course,
sh(1) will permit you to set ${name}_program from
rc.conf(5) or the script itself even if command is unset. In that case, the special properties of ${name}_program are lost, and it becomes an ordinary variable your script can use for its own purposes. However, the sole use of ${name}_program is discouraged because using it together with command became an idiom of rc.d scripting.()
which actually means : you have the name what you want to use then _ then the kind of things you want to use, if it is an argument or a cmd or paramerters ...
that what isn't clear for me.
plus you have apparently parameters which you need to spell completely and others where you need to give a name to it.
the thing I need to translate is
Bash:
su -m -c 'screen -S flood-rtorrent -dm rtorrent' flood
and
Bash:
su -m -c 'screen -S flood-rtorrent -X quit' flood
.
I don't want necessarely a solution to that, I want to understand what is the hierarchy in all those command or args because it seems that there is no apparent logic to it. I can't even figure it out if the function into rc.d like start_cmd are more elevated than run_rc_command from rc.subr since there are on the same level in the file from syntax point of view.
