>> 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.

well...in 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
already.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."