Re: dcfgtool and clones
On Jun 1, Craig Sanders wrote
> It should NOT attempt to be some universal replacement for
> package-specific config files.
i agree.
> All that is needed is a set of "key=value" pairs in a plain text file. Take
> a look at FreeBSD's /etc/sysconfig or NextStep's /etc/hostconfig for an
> example.
>
> This is not only simple to implement, but it is also simple to
> parse...and it allows the sysadmin to change the setup with
> vi/pico/ae/joe/emacs or whatever. Later, a GUI or web front end can be
> layered ON TOP of this.
that's what we don't want : one big file with all settings.
but it will be a text file, so anyone can edit it.
> parsing the files in shell is simple:
>
> source /etc/sysconfig
but that way you have to look at /etc/sysconfig, what is done there.
a simple call to the database to say "give me thiese values" is more
transparent and not (much?) slower.
> parsing it in perl is almost as easy. The following code fragment reads
> /etc/sysconfig into an associative array called $config.
we don't have perl in system bootup scripts, i hope. and of course you
can also get the informations from the database with perl (using a small
call).
> So, a decision needs to be made: whether to allow only simple
> assignments or to also allow complicated assignments like
> "foo=`cat /etc/bar`".
no, we shouldn't have this one. it says, that we would have one file per
variable. not a good idea. the dtxtdb/configtool is to get rid of such
stuff.
> at minimum, we need to support sh/bash/ksh/zsh, and perl.
no problem. also csh/tcl/whatever shouldn't be hard to support.
(anything can be used, that can call a program an eveluate it's output).
> we need code fragments in all of these languages to add, read, modify,
> and delete (comment out) "name=value" pairs....and do it WITHOUT
> disrupting any comments or the order of assignment statements in the
> file.
that's why we don't want one big file and we don't want direct access. a
small tool will do all this, the languages will "only" need to exec it
with the right parameters. and this way it should not be possible to
destroy the database or at least not that easy like a buggy script could
do it.
> btw, i don't care what the file is called. /etc/sysconfig is just an
> example.
your comments are right. but we don't want one big file. a small
directory with several files, and a tool to access them will be better.
regards, andreas
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: