Subject: Re: take2
To: Luke Mewburn <lukem@goanna.cs.rmit.edu.au>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-userlevel
Date: 12/03/1999 10:59:48
In some email I received from Luke Mewburn, sie wrote:
> 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.
[...]
> 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'.

No, but I've had to hack at a lot of shell scripts over the years.  Some
have been semi-application in size (in the thousands of lines).  Getting
your head around variable creation using eval is enough fun for me, having
to deal with multiple levels of quoting because I'm writing a shell script
that is being assigned to a variable is not something I'm looking forward
to even having to read.  I don't mind having things like killall or others
in /etc/rc.subr to use, but the running of a shell srcipt in a variable
really doesn't turn me on.

(2) is my main issue with rc_run_command (the others were just supporting
cast members with no real basis, except you pressed me on it so I made
them up).

Darren

p.s. I hope it's an unintended oversight that run_rc_commands is seriously
lacking when it comes to comments.  The first step (explaining the function)
has been taken, which is good.