On Mon 2002-10-28 (13:57), Peter Pentchev wrote: > This had better be ". /etc/defaults/rc.conf; source_rc_confs; ..." :) > > I have been thinking for quite some time of writing a little utility > that parses various configuration file mechanisms and allows the > administrator to specify which config mechanism to use for which > program. I have a simple design in mind, which would allow direct > variable setting, use of /etc/rc.conf, use of other configuration files, > use of daemontools-style envdirs, and a couple of others, but so far, > there has been no time to actually start writing a simple > proof-of-concept thing. Funny now, the timing; I was thinking of > writing up a simple rcenv(1) today or tomorrow, and then I saw this > thread :)
Go for it (please!). Check out: Subject: non-variables in rc.conf (Re: proposed code: automatic setting of hostname from MAC address) Message-ID: <[EMAIL PROTECTED]> On arch mailing list: <<<=== Abstracting the configuration away from "shell scripts and functions" would allow us to pull the configuration in from other locations in the "backend". The one basic example I did perform was in the order of (replace \ns with real enters): eval `echo 'g/^[:space:]*$/d\ng/^#/d\ng/$/s//;/\ng/./' | ed -s \!'cat /etc/rc.alternate.conf'` Anyway, assume that we can get our network configured beforehand, and we can then use ldap, NIS, or whatever (netinfo?) to get our configuration. ===>>> When we can finally get rid of non-variables in the configuration system we no longer rely on 'sh', and we can read configuration using any programming language, and/or (even better) back the configuration up with LDAP or whatever. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
