Some minor nits:
@@ -479,7 +479,7 @@
<important>
<para>The names of all &man.rc.conf.5; variables used
exclusively by our script <emphasis>must</emphasis>
- have the same prefix: <envar>${name}</envar>. For
+ have the same prefix: <envar>${name}_</envar>. For
example: <envar>dummy_mode</envar>,
<envar>dummy_state_file</envar>, and so on.</para>
</important>
You should add the same correction to the very next sentence, which reads:
Note: While it is possible to use a shorter name internally, e.g., just
msg, adding the unique prefix ${name} to all global names introduced by
our script will save us from possible collisions with the rc.subr(8)
namespace.
@@ -491,15 +491,6 @@
our script will save us from possible
collisions with the &man.rc.subr.8; namespace.</para>
- <para>As long as an &man.rc.conf.5; variable and its
- internal equivalent are the same, we can use a more
- compact expression to set the default value:</para>
-
- <programlisting>: ${dummy_msg:="Nothing
started."}</programlisting>
-
- <para>The current style is to use the more verbose form
- though.</para>
-
Not sure why you felt this paragraph needed to be removed.
@@ -512,7 +503,11 @@
<callout arearefs="rcng-confdummy-msg">
<para>Here we use <envar>dummy_msg</envar> to actually
- control our script, i.e., to emit a variable message.</para>
+ control our script, i.e., to emit a variable message.
+ Use of a shell function is overkill here, since it only
+ runs a single command; an equally valid alternative is:</para>
+
+ <programlisting>start_cmd="echo \"$dummy_msg\""</programlisting>
While you are technically correct, I think you misunderstood the
writer's intent, which was to show how an rc.conf(8) variable can be
used in a subroutine to control the behavior of the command. I agree
that the example isn't a very good one (in that it doesn't depict a
valid use case), but I think the "spirit" is correct. Maybe you can
suggest a better example?
Cheers,
Mike.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
