[ On Thursday, March 16, 2000 at 12:46:43 (-0500), der Mouse wrote: ]
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> Someone else asked what a traditional monolithic file gives that
> 
> 	cat `rcorder /etc/rc.d/*` > /etc/rc
> 
> doesn't.  I've now looked at /etc/rc.d/*, and I can answer that in one
> word: comprehensibility.  The only way in which such an rc file is
> better than the split-up scheme is that I don't have to grep around to
> figure out which script something is started from.

As a side comment I'll note that most of the script naming seems quite
logical to me now except for the "empty" place-holder scripts that
simply help determine dependencies and act as additional state nodes.
I'd like to see a recognisable naming convention be used for them so
that I can see by their names that they don't actually do anything
themselves.

>  It's still full of
> all the other problems, like sourcing rc.subr and rc.conf a dozen times
> each

OK, then throw in a tiny filter to eliminate all the extra reads....

> like having to grok a complicated set of shell functions in order
> to have a clue what's going on (and in particular what I need to do to
> get some desired effect).

If you're talking about what's in /etc/rc.subr, well first off I don't
find it all that complicated, and it's well documented internally to
boot.

I think that once the overall API is well enough documented in more
obvious and traditional places there'll be no need to even peek at the
underlying framework -- the higher-level functions are already quite
simple to understand in my mind and I'm sure the finer details will come
clear soon enough.  Obviously all the lower level details are repetitive
anyway so why do you want to see them in full all of the time?

> The resulting script is almost as much of a
> maintenance nightmare as the original split-up files were.

Well of course!  So, if you treat the result as an opaque blob much as
if it was a binary executable then you'll not be tempted to try and
maintain it as a single entity.  Edit the components as source and
"compile" the monolithic script if that's what you feel you have to
do....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>