Darren Reed writes:
> > run_rc_command was initially developed as a method of reducing
> > unnecessary code duplication in scripts (such as parsing command line
> > arguments, checking for running processes, etc), and it does this
> > well. You haven't explained very well what's wrong with run_rc_command
> > in its role of supporting start/stop/... type operations.
> 
> 2. In some of your rc scripts, you have start_cmd='\.  What happens when
>    I want to use 's and "s as a part of a script ?  I need to go through
>    stupid hoops for quoting.

It's really not that difficult.


> 3. It isn't immeadiately clear what `options' the netbsd dhcpd script
>    supports (in terms of start/stop, etc).

Yes it is. It's documented that run_rc_command supports
"start/stop/restart/status" by default, along with any others given
to run_rc_command. That will be documented in rc(8), along with other
details of the system.


> 4. On Solaris, init scripts are _independant_.  On NetBSD, for better or
>    worse, they're all dependant on rc.subr providing functions.

We've been relying upon rc.subr for other functions (checkyesno,
mountcriticalfs, etc) it provides to our rc system for over two years
now. I just don't buy this argument. That's like saying we shouldn't
have C libraries.


Speaking as someone whose actually written a lot of traditional
style `do everything in the script' approach, and converted them
to using run_rc_command, the overhead in using the latter is much
less.  mrg's original work was a bunch of stand-alone scripts, and
adding or changing functionality was much more difficult in that
environment than using run_rc_command.

Darren, you appear to be arguing against run_rc_command based on
spurious hand-waving, rather than speaking as someone whose sat down,
written the scripts, and compared the benefits of both. I.e, `put up
or shut up'.