From: utzoo!decvax!microsof!gordonl
Newsgroups: net.unix-wizards
Title: "." files and defaults
Article-I.D.: microsof.2394
Posted: Thu Oct 21 13:42:14 1982
Received: Fri Oct 22 02:27:54 1982

I'm very interested in some of the issues being discussed re: "." files.
These usually represent "default" files of some kind.

We feel that UNIX programs can be broken into two categories,
"filters" and "interactive".  A program is "interactive" if its sole
use is direct interaction with a user.  Vi and the rand editor are
thus interactive.  Programs which may be used non-interactively are
then filters.  This makes sh and csh filters, not interactives.

This distinction is important because we only allow "default setups"
for interactive programs.  Such things as vi, news, more, and readmail
should properly have files containing defaults of various kinds.  We
do not allow filter programs to read "default files" as that might
cause the operation of the filter to differ, depending upon the
default file's contents.  This will damage the UNIX software-tools
approach to life; no shell script, system(3) or popen(3) program would
be safe in their own beds if various "standard" filters start to act
differently between various systems or even between different users!

We're using a little library package to read default files.  System
defaults for program X reside, by convention, in /etc/default/X.
Thus, the filesystems that 'df' and 'fsck' default to scan are
stored in
	/etc/default/df         and
	/etc/default/fsck
respectively.  An entry in
	/etc/default/lpd
tells lpd the number of banner pages to print;
	/etc/default/dump
tells dump the default dump media  (many small systems don't have
mag tape, /dev/rmt1 is of little use to them!)


We envision using this mechanism in place of most "." files.  Presumably
the convention will be
	$HOME/default
with files such as
	$HOME/default/login
	$HOME/default/news
	$HOME/default/mail
etc.


If there is sufficient interest, I'll post the man page and sources
for these routines.  They're quite simple, and designed to allow
information of arbitrary format to be kept in these files.  I'd like
for the unix community, as represented by this group, to reach a
concensus about how this issue is to be handled.

	gordon letwin
	microsoft