On Fri, Feb 01, 2002 at 02:47:30AM -0330, Paul Fardy wrote:
> These examples, _and_yours_, are examples that suggest that
> /etc/rc.conf has a fundamental principle that
> is supreme. One can set up all the requisite parameters (e.g. you
> can create sendmail.cf, named.conf, tune inetd.conf, compile psm
> into the kernel or install any of various screen savers), yet one
> can still set an appropriate variable
> which will not enable the feature.
It will not enable it, no. Nor will the feature be disabled if it for
some reason already was enabled.
> >Not enabling something is *not* the same thing as disabling it.
> But I think that the intent in /etc/rc.conf is that enable="NO"
> _is_ the same thing as disabling it. You might say "If that were
Consider that the actual code in the various rc* start scripts is
in most cases of the form:
Some cases are instead
A cursory search found a total of one instance where foobar="NO" actually
makes something happen, and it was not of the form foo_enable="NO"
(The single exception I found is
For all other variables one can set in rc.conf foobar="NO" means
Looking at the code the intent certainly seems to be foo_enable="NO"
shouldn't do anything.
> the intent, they'd have used _______." What word should we use
> to indicate the absolute YES or NO that some of us believe
> should be the simple correct interpretation?
I.e. describing the desired state of the feature instead of the desired
action to be taken.
There are of course several people who feel that the current behaviour
is the intuitive and obviously correct interpretation and would prefer
not to have it changed.
<Insert your favourite quote here.>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message