> I don't see what your problem is.  Isn't Bourne shell a
> configuration language of sorts?  Aren't shell scripts real
> configuration files?

No, because:

	* They cannot be edited robustly by programs.
	* They cannot be verified as meaningful by programs.
	* There is a high probability of error when a neophyte user
	  edits a shell script (or something in another complicated
	  language) as opposed to a well-designed configuration file.
	* Shell scripts typically do something other than just
	  configuration (although they occasionally don't).

A good configuration file should generally not be Turing complete, and
should always use a syntax intended to be read by people, not /bin/sh.

I guess my idealism is lost on this list.  Let me try to be a little
more practical: right now, all Unix variants are very hard to use.  We
have a lot of Linux and NetBSD users at MIT who have no experience
administering operating systems or writing shell scripts.  Because of
the slipshod way all Unix systems configure and start their
subsystems, it is very difficult to handhold these users through the
process of dealing with even very basic tasks.

An example of a well-designed subsystem is inetd.  You run it as
"inetd" with no arguments (no need for a separate startup script), and
it reads /etc/inetd.conf to decide what to do.  /etc/inetd.conf is
simple and includes a syntax for writing comments so that it can be
self-documenting.  Although the functionality of inetd is mildly
esoteric, users rarely make mistakes or get confused trying to edit
/etc/inetd.conf; when they do screw up, inetd will just skip the
broken lines and still provide the remaining services properly.

An example of a poorly-designed subsystem is the network startup.  You
have to run some number of invocations of ifconfig and route, each
with half a dozen arguments.  This is "simplified" by a script
/etc/netstart (which contains both operating system code and
configuration data for other subsystems, and which must be hand-merged
with new revisions of NetBSD) combined with a mishmash of
configuration files /etc/myname, /etc/mygate, /etc/hosts, and some
number of /etc/hostname.something files, each evidently designed to
hold as little data as possible so that they can be trivially read by
a shell script.