On Thu, Aug 07, 2008 at 01:06:38AM -0400, Mike Meyer wrote:
>On Wed, 6 Aug 2008 22:34:51 "Michael B Allen" <[EMAIL PROTECTED]> wrote:
> > But of course the format of data in a database is largely irrelevant.
> > You could implement the same thing with dbm files or a more forgiving
> > text format.
>
> Right. For that matter, you could leave the data in shell scripts, and
> build a layer of meta information and tools to manipulate these things
> - which is similar to what I see in Linux distros.
>
> The Solaris smf tools provide some nice facilities: one is single
> interface to start, stop, check and restart all the services on a
> system. We pretty much have that, as they all use the same basic
> arguments to their rc scripts. The only issue is figuring out which
> directory to find the rc script in.
I use for this simple script [1] plus some programmable completion.
>
> The other is a single interface to enable, disable and query the
> status of all the services. All we really have is the last one: you
> can run the script with the rcvar argument, and it'll list the
> appropriate variable if it's set, and the value it's set
> to. Maybe. Not all of them support this yet.
> > As for getting rid of rc.d scripts, yes they're decrepit and I would
> > love to see them go but they're simple and third party software may
> > depend on them being the norm.
Can You please be more elaborate? Yes, rc.d scripts have some problems,
but I don't think We need to get rid of them.
[1]:
$cat /usr/local/bin/service
#!/bin/sh
name=$1
cmd=$2
. /etc/rc.subr
if [ -z "${name}" -o -z "${cmd}" ]
then
echo ${0##*/} service_name command
exit 3
fi
if [ -r "/etc/rc.d/${name}" ]
then
run_rc_script "/etc/rc.d/${name}" ${cmd}
exit 0
fi
if [ -r "/usr/local/etc/rc.d/${name}" ]
then
run_rc_script "/usr/local/etc/rc.d/${name}" ${cmd}
exit 0
fi
if [ -r "/usr/local/etc/rc.d/${name}.sh" ]
then
run_rc_script "/usr/local/etc/rc.d/${name}.sh" ${cmd}
exit 0
fi
echo "service '${name}' not found"
exit 2
--
Adios
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
