From: utzoo!decvax!ittvax!tpdcvax!bobvan
Newsgroups: net.unix-wizards
Title: Re: Microsoft's answer to dot files
Article-I.D.: tpdcvax.183
Posted: Fri Oct 22 19:17:44 1982
Received: Sat Oct 23 04:42:13 1982

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)