Subject: Re: take2
To: Darren Reed <email@example.com>
From: Luke Mewburn <firstname.lastname@example.org>
Date: 12/03/1999 10:38:38
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'.