bobvan (10/23/82)
In a recent unix-wizards article, Gordon Letwin described Microsoft's solution to the "dot file" proliferation problem. In their scheme, each command needing default information gets it from the file /etc/default/<command name>. This sounds like a good idea, but I'm afraid that Microsoft has carried it too far. One thing I'll always flame about is redundant information, so "flame on". Quoting from Letwin's article: The filesystems that 'df' and 'fsck' default to scan are stored in /etc/default/df and /etc/default/fsck Allow me to extend this for you: The filesystems that 'dump', 'mount', 'umount', and 'swapon' default to scan will be stored in /etc/default/dump, /etc/default/mount, /etc/default/umount, and /etc/default/swapon Now I've got six files to edit every time I want to add or remove a filesystem from my configuration! I think you can see my point, so "flame off". /etc/default is a fine place to store default command parameters as long they are not redundant. Criticism should be accompanied by a constructive suggestion, so here here goes. I like to think of filesystem information in tabular form -- an array, if you will. The index is the filesystem in question, and the things we might want to know are: the block special device, the file system pathname it is normally mounted on, its type (read/write, read only, swap, or other), its dump frequency in days, or its pass number (if you've hacked fsck to fork and keep more than one arm moving at a time). [[Berkeley UNIX gurus will instantly recognize this as the description of the /etc/fstab file]]. This information can be represented either as many individual arrays of the appropriate data type, or as one array of data type "filesystem description". I liken this to using structures in C. Perhaps the lack of structures in BASIC (Microsoft's largest selling language) is the reason they didn't see this. Putting default filesystem information in six files is scarcely an improvement over the "old days" when it was hard coded into dump.c and df.c. The Berkeley /etc/fstab scheme is far better. Lest the Berkeley authors get a swollen head, I should also flame about the proliferation of /etc/tty* files. We've got ttys, ttytype, and ttywhere; all indexed by tty name. These three should be consolidated. I assume that they were left separate because ttys stood on its own for so long. I think Microsoft has also gotten carried away with the distinction between a filter or non-interactive command and an interactive command, such as an editor. The shell and csh were explicitly mentioned in the article as being filters, not interactive. The article also states that filters cannot have default files -- otherwise their operation might differ from system to system or user to user. While it is true that the shell and csh fit the classical definition of a filter, I think it a mistake to take away their default files on these grounds. Consider the fate of the default command search path variable used in both shells. The presence of this variable is one of the things that gives UNIX its great flexibility. One path for secretaries, one for engineers, one for people on project X, another for project Y, etc. An easily changeable user interface has always been a great selling point for UNIX. Preventing the user from setting interactive shell defaults would certainly not be an improvement. If Microsoft is determined to continue with the sharp distinction between filters and interactive programs, they should consider shells as members of both classes -- they are used in both ways. Interactive shells "know who they are" (isatty(0)), and could read defaults for interactive users. I haven't thought this one through, but it doesn't look like much improvement over the existing scheme. Mr. Letwin says the he'd like the UNIX community, as represented by this group, to come to a consensus about how the "dot file problem" should be handled. From what he has described, I cannot vote in favor of Microsoft's scheme. Bob Van Valzah (...!decvax!ittvax!tpdcvax!bobvan)
johnl (10/29/82)
Forwarded from Mark Kampe, ima!ism780!mark
Part of our efforts at INTERACTIVE have been directed towards making
system management easier by localizing the important system information
in a small number of places. Like Berkeley and Microsoft, we want to
allow system managers a great deal of freedom in tailoring their devices
and defaults. Unlike Berkeley and Microsoft, we wanted to avoid a
profusion of files and syntaxes. We also wanted to avoid the error prone
complexities of forcing a system manager to update multiple files or
perform some post-processing operation on the files after editing them.
Our solution is based on "attribute structured files". These files all
have a uniform syntax and are maintained in ASCII form. There is a set
of simple querry routines for extracting information from these files, so
it is easy for programs to use them also. We use these files (the same
syntax) for many different applications. The files consist of named stanzas,
each containing a series of attribute=value statements. The syntax provides
for multiple and default vaues. Two attribute structured files that are
directly relevent to this discussion are /etc/filesystems and /etc/ports.
***/etc/filesystems***
default:
mount = true
check = true
free = true
vol = ISC001
cyl = 608
skip = 12
dumpdev = /dev/rmt8
dumpden = 1600
/:
dev = /dev/hp0
size = 12300
check = 1
/a:
dev = /dev/rp9
size = 45600
/70sccs:
dev = /dev/rp1
size = 62016
/oldsrc:
mount = true,readonly
dev = /dev/rp2
size = 62016
All file system relevent programs accept file system names or device names,
and use /etc/filesystems to map between them. All programs that need to know
file system parameters get them from this file. All defaults come from
this file. In general, adding a new file system is as simple as
add a stanza such as
/newfs:
dev = /dev/rp4
size = 32000
typing the two commands
mkfs /newfs
mount /newfs
And from then on, it will be mounted, dumped, checked and
everything else by default.
***/etc/ports***
default:
enabled = true
erase = 010
kill = 025
speed = 9600
herald = "\r\nINTERACTIVE System/Three: ISM780\r\nlogin:\007 "
logger = /priv/login
printer = diablo
term = intext2
/dev/console:
speed = 1200
/dev/tty00:
/dev/tty01:
* This port is bad for some unknown reason, should be researched
* it seems to generate alot of noise when disconnected
/dev/tty03:
enabled = false
/dev/tty17:
speed = 1200
parity = none, odd+inpck, even+inpck
term = dialin
super = false
/dev/tty50:
loc = "ftp/INnet link to ISM1"
program = "/etc/ftplogger -pw -r4"
speed = 4800
/dev/ipl0:
enabled = false
loc = "ftp/INnet link to ISM70"
program = "/etc/ftplogger -pn"
Init and getty find out everything they need to know about a terminal from
this file. The last two stanzas show how the file is also used to control
non-login ports. The attributes of all communication ports and all of their
associated daemon processes are also controlled from this one file.
A complete description of all of the parameters and how they can be used
would be rather voluminous (that is why we have a system manager's handbook),
but the important punchlines are:
1) all information about a type of system resource is localized in
one file.
2) the file is human readable and human modifiable.
3) there are always reasonable system defaults and the system
manager can impose his own defaults
4) in most cases, changing the entry in that file is the only
thing that has to be done.
5) all programs and system management utilities get everything
they know out of those files.
6) we use the same syntax and query routines for system management
databases
system ports (incomming and outgoing)
file systems
queuing system queues and devices
word processing configuration
7) the query routines are generally available and are used by many
applications developers as well.
---mark---
--------
--------