quotes around YES or NO are not necessary in /etc/rc.conf?

[Polytropon]

On Tue, 10 Jun 2014 13:02:26 +0100 (BST), Anton Shterenlikht wrote:
> Am I right that quotes around YES or NO are
> not needed in /etc/rc.conf?

The file /etc/rc.conf basically is a Bourne shell script,
and it usually only contains variable=value pairs, so the
rules for this construct apply: Quotes aren't needed if
the value is just a single word, or if spaces are properly
escaped, as you correctly assume:



> It seems both forms, e.g.:
> 
> ntpd_enable="YES"
> lpd_enable=YES
> 
> are understood.

Also imagine things like:

	foo_flags=BLA\ MOO\ MEOW

Still it definitely looks better with quotes.

Also consider the following: If double quotes are used, you
can use evaluation within the quotes (even though you probably
don't do this inside /etc/rc.conf), and if single quotes are
used, things are associated 1:1, like:

	FOO=`/sbin/date "+%Y-%m-%d %H:%M:%S"`
	bar_flags="set date = $FOO"
	baz_flags='SYS$MANAGER'

This is consistent with "man sh". But note that /etc/rc.conf is
for sure not a place to run commands from. :-)



> I think quotes might be coming from
> incorrect reading of rc.conf(5).
> It has lines like:
> 
>      rc_debug    (bool) If set to “YES”, enable output of debug messages from
> 
> or
> 
>      rc_info     (bool) If set to “NO”, disable informational messages from
> 
> however this is just quoting the special
> words from the rest of the sentence.
> The boolean value is either YES or NO.
> The quotes are not needed.

For YES and NO, they are not needed, but in my opinion, using
quotes for _any_ setting makes the whole thing consistent and
less error-prone (for missing a required quote, or worse, an
escape as shown above). The fact that rc.conf is just a shell
script isn't that clear, but read paragraph 2 of DESCRIPTION
in its manpage:

     The purpose of rc.conf is not to run commands or perform system startup
     actions directly.  Instead, it is included by the various generic startup
     scripts in /etc which conditionalize their internal actions according to
     the settings found there.

A few lines ater on:

     Options are set with ``name=value'' assignments that use sh(1) syntax.

This is what "makes the rules". :-)

Additionally, note that the manpage does not use "..." to
emphasize a value _as_ a value (separating from the rest of
the sentence", but ``...'', which is definitely not sh syntax
and cannot be confused with either "..." (quoting with evaluation),
'...' (quoting without evaluation), or even `...` (subcommand
result).


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...