gordonl (10/25/82)
There has been some misunderstanding as to the defaults system we're using at Microsoft. The orginal article describes a system meant to substitute for most of the things "." files are used for. The title of the article, to say nothing of the text, makes that clear. Several people have responded concerning the flexibility of adding/removing file systems from dump lists, a completely seperate topic! The specific examples given had to do with such things as the number of banner pages to be printed by "lpd". 0 pages is the right thing on a single user system with a slow serial printer, we prefer 2 pages on our line printer. Its not clear to me how the berkeley "fstab" system handles this! Another topic was the list of filessystems to be scanned by "df". This is NOT the same as the list of all file structures; we certainly dont have our default "df" list include all our various private filesystems. Since the issue has been brought up, I'll describe how the defaults system addresses the file system issue. The individual default files have contents like: KEYWORD=<value string> One possible solution is to have the KEYWORD encode the kind of data we have. Thus, we could have FILSYS_ALL= /dev/root /dev/usr /dev/tmp FILSYS_DUMP=/dev/root /dev/usr FILSYS_DF= /dev/usr in /etc/default/filsys. Various programs interested in file systems could fetch their lists from this file. They still have access to /etc/default/<name> for individual option defaults. Another possibility is to link many of the /etc/default files together. For example, /etc/default/dump /etc/default/restor /etc/default/dumpdir /etc/default/tar are all links to the same file which describes the default tape device. One could encode private switches for, say tar, in the form TAR_SWIT=-r -u -e Personally, I prefer /etc/default/filsys to contain all the info about file systems. There has also been some confusion about the wisdom of private configuration files for the filters "sh" and "csh". People seem to be suggesting that our viewpoint is bogus for exactly the reason I first brought it up: "sh" and "csh" act as both filters and interactive programs; there needs to be an understanding of what both types of programs may do to prevent the kind of problems (with PATH, for example) that we're seeing. I know its true that sh and csh are tougher cases than a simple binary choice; one of the things that still seperates humans from computers is the ability to deal with such problems... Gordon Letwin Microsoft