Subject: Re: Keeping /etc/defaults and /etc/rc.d in-sync
To: Frederick Bruckman <>
From: Andrew Brown <>
List: tech-userlevel
Date: 12/28/2001 16:50:20
>> lemme try this again.  since its first revision, the sshd script (for
>> example) has contained a line that said
>> 	command="/..."
>> for some value of "...".  then, in june of last year, support for
>> rc.conf.d was added to rc.subr so that individual rc.d scripts could
>> have individual files in rc.conf.d as an alternative to settings in
>> rc.conf.  it can also be used to set, eg, the value of the command
>> variable, so that you can run an *alternate* version of something...
>> perhaps something you installed yourself or got from pkgsrc.
>OK. I see how that would work. It looks more like an undocumented hack,
>though, than something we can rely on.

well...if i went and documented it, would that stop it from being a
hack?  seriously though, this is an ideal application of this tool.

>> in the face of this, i can't see how allowing *further* settings in
>> rc.conf is necessary.  at least involving the command.
>I would like to have the same functionality in "rc.conf" that's
>available in "rc.conf.d", and I believe it should be documented in
>"rc.subr" in the same place all the other ${name}_foo options are
>documented. order to change it such that $command was handled as,
instead, a variable like $rcvar...there would have to be bit of
rearchitecting of rc.subr, and it might not end up as pretty.
seriously though, i think that rc.conf.d does exactly what you need

|-----< "CODE WARRIOR" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."