4 可配置的虚拟脚本
现在我们来给我们的虚拟脚本增加一些控制参数吧。正如你所知， rc.d 脚本是由 rc.conf(5) 所控制的。 幸运的是，rc.subr(8) 隐藏了所有复杂化的东西。 下面这个脚本使用 rc.conf(5) 通过 rc.subr(8) 来查看它是否在第一个地方被启用，并获取一条信息在启动时显示。 事实上这两个任务是相互独立的。一方面，rc.d 脚本要能够支持启动和禁用它的服务。另一方面， rc.d 脚本必须能具备配置信息变量。 我们将通过下面同一脚本来演示这两方面的内容：
#!/bin/sh . /etc/rc.subr name="dummy" rcvar=`set_rcvar`start_cmd="${name}_start" stop_cmd=":" load_rc_config $name
eval "${rcvar}=\${${rcvar}:-'NO'}"
dummy_msg=${dummy_msg:-"Nothing started."}
dummy_start() { echo "$dummy_msg"
} run_rc_command "$1"
在这个样例中改变了什么？
- 变量 rcvar 指定了 ON/OFF 开关变量的名字。包含来自 rc.subr(8)
中变量名是为了调用不同操作系统所采用的不同规定的
set_rcvar。也就是说，FreeBSD 坚持使用 ${name}_enable 样式而 NetBSD 的 rc.conf(5) 中使用的只是 ${name} 变量的形式。例如，我们在 FreeBSD 中使用 dummy_enable 来控制我们的脚本而在 NetBSD 中使用 dummy 来控制。 - 现在
load_rc_config在任何 rc.conf(5) 变量被访问之前就在脚本中被预先调用。 -
注意: 检查 rc.d 脚本时，切记 sh(1) 会把函数延迟到其被调用时才对其中的表达式进行求值运算。 因此尽可能晚地在
run_rc_command之前调用load_rc_config， 以及仍然访问从方法函数输出到run_rc_command的 rc.conf(5) 变量并不是一个错误。这是因为方法函数将在load_rc_config之后， 被调用的run_rc_command调用。 - 如果自身设置了 rcvar， 但指示开关变量却未被设置，那么
run_rc_command将发出一个警告。如果你的 rc.d 脚本是为基本系统所用的，你应当在 /etc/defaults/rc.conf 中给开关变量添加一个默认的设置并将其标注在 rc.conf(5) 中。 否则的话你的脚本应该给开关变量提供一个默认设置。 范例中演示了一个可移植接近于后者情况的案例。 -
注意: 你可以通过将开关变量设置为 ON 来使 rc.subr(8) 有效， 使用 one 或 force 为脚本的参数加前缀，如 onestart 或 forcestop 这样，会忽略其当前的设置。 切记 force 在我们下面要提到的情况下有额外的危险后果，那就是当用 one 改写了 ON/OFF 开关变量。例如， 假定 dummy_enable 是 OFF 的，而下面的命令将忽略系统设置而强行运行
start方法：# /etc/rc.d/dummy onestart
- 现在启动时显示的信息不再是硬编码在脚本中的了。 它是由一个命名为 dummy_msg 的 rc.conf(5) 变量所指定的。这就是 rc.conf(5) 变量如何来控制 rc.d 脚本的一个小例子。
-
重要: 我们的脚本所独占使用的所有 rc.conf(5) 变量名， 都必须具有同样的前缀：${name}。 例如：dummy_mode， dummy_state_file，等等。
注意: 当可以内部使用一个简短的名字时，如 msg 这样，为我们的脚本所引进的全部的共用名添加唯一的前缀 ${name}，能够避免我们与 rc.subr(8) 命名空间冲突的可能。
只要一个 rc.conf(5) 变量与其内部等同值是相同的， 我们就能够使用一个更加兼容的表达式来设置默认值：
: ${dummy_msg:="Nothing started."}尽管目前的风格是使用了更详细的形式。
通常，基本系统的 rc.d 脚本不需要为它们的 rc.conf(5) 变量提供默认值， 因为默认值应该是在 /etc/defaults/rc.conf 设置过了。但另一方面，为 ports 所用的 rc.d 脚本应提供如范例所示的默认设置。
- 这里我们使用 dummy_msg 来实际地控制我们的脚本，即，发一个变量信息。