From: utzoo!utcsrgv!utcsstat!geoff
Newsgroups: net.unix-wizards
Title: stamp out dot files!
Article-I.D.: utcsstat.366
Posted: Sun Oct 24 03:26:48 1982
Received: Tue Oct 26 07:30:35 1982

This is a rebuttal of a previous article.
My comments appear in square brackets.

>From utcsrgv!utzoo!decvax!cca!fc@usc-cse@sri-unix Wed Oct 20 06:29:32 1982
Date: 16 Oct 1982 11:29-PDT
Some notes:
	1)	Filenames are defined as being made up of a set of
		characters of which '.' is one. Removing '.' from
		that set is unacceptable due to the large inconvinence
		of modifying every program and script that uses files.
		It is further inconvinience because of the increase in
		space and time required to check the special case. In
		fact, '.' would have to be a very special case since we
		probably all still want it in the middle of files, just
		not as the first character. (That of course would apply
		to not the first character after '/' in a full pathname.
[ I don't think anyone is saying that the kernel should reject
  filenames beginning with dot; I'm asking that people who write and
  maintain programs refrain from using a dot as the first character of a
  filename in order that it be an invisible, second-class file. Equal
  rights for dot files! ]

	2)	It is no more reasonable to have all files beginning
		with a dot in the same directory as having all files
		that begin with a ':' in the same directory. How about
		'l' and 'R' as well? Whay not alphebetize everything by
		directory??? Because, the directory hierarchy is central
		to the concept of the unix environment. It is one of the
		great powers of the system to allow the use of the same
		name in different places in the tree to have contextual
		signifigance. Take for instance EMACS's clever way of
		remembering where you were in an edit. Centralizing this
		would be unreasonable, while having a file in each path
		that is called emacs_last_edit would not help me to know
		what is or is not in the directory or what it is used
		for. It would merely get in the way of seeing what I
		really want to know.
[ I don't think any of us are doctrinaire about this; I just want
  people to stop expecting dot files to be invisible.  Since there are
  increasing numbers of dot files cluttering our login directories, I'd
  like to see files named `.thisrc' *in one's login directory* renamed to
  something like `my/thisrc'.  This way the files are visible, yet out of
  the home directory. ]

	3)	For those who really want to see it all, the ls -a alias
		(in the csh) or a file in your bin directory (assuming
		it is in your path) called ls that contains 'ls -a $*'
		does the job quite well enough.
[ Nonsense.  `ls -a' also prints . and .., which are generally only of
  interest to those patching file systems.  Also, in the shell, `*' needs
  to match dot files. ]

	4)	It is unreasonable to demand of a program that it name
		files by your convention or tie everything to shell
		variables. The shell is simply another program, and it
		should certainly have the same freedom of naming
		conventions as any other program. If it really disdains
		you, modify the shell to allow the '.' files to be set
		to other names through the use of a shell variable.
		(while you are at it modify the csh and all other
		programs that use this convention to allow external
		variables to replace internal filenames.) In fact, since
		you are so anxious, make a simple user accessable
		facility for facilitating this so the rest of us can
		trivially use shell variables for setting internal
		names.
[ More nonsense.  Most programs already follow a naming convention laid
  down by Berkeley: a program, foo, calls its file for user bar
  `~bar/.foorc'.  My proposal is to change to `~bar/my/foo' which makes
  the file visible yet unobtrusive.  No more second-class files.  As side
  benefits, * in sh will match this file, with *no* mods to sh, and ls
  will print it, also with no mods. ]

	In summary, '.' files make a lot of sense, are useful, and can
easily be made visible by default if the user so desires. I for one want
them to stay as they are. I think that after using the system for a few
years most people would agree with me.
[ In summary, dot files are a damned nuisance, are second-class
  invisible files.  They can be made visible to ls by also exposing . and
  .., which most people are uninterested in, and can be made visible to
  sh by .* which also matches . and .. .  I for several can't wait for
  them to change name and for people to stop skipping all files beginning
  with dot.  (Any one at research care to comment?  I'm sure that the
  convention of skipping dot files was simply a quick-and-easy way to
  miss . and .., and was not intended to produce a second class of
  files.) Having used UNIX since v6 and 1977, I resoundingly disagree
  with you.
  
  For the efficiency freaks in the house, a separate directory for
  start-up files would likely be faster since the home directory would be
  smaller and programs looking for start-up files would quickly get into
  the relatively small directory of start-up files, also quite fast.
  
  Perhaps more to the point, why do so many programs need start-up files
  to initialise them?  Maybe they have the 4.1BSD disease: so many
  options that they use both cases of the alphabet, digits and greek
  characters as flag characters (see ls, for example).  Should these
  programs instead be reading environment variables? They could be either
  like ROGUEOPTS, specific to one command, or quite general, something
  like VERBOSITY=naive.
  
  I'm not suggesting a massive sweep of all UNIX* source to replace dot
  files with files in a directory in the user's home directory.  I'm
  simply stating my opinion on dot and start-up files.  I would hope that
  those who feel the need of start-up files would in future put them in a
  common directory with visible names.  It would also be useful if sh and
  ls were modified to match and print all files but . and .. by default.
  
  Geoff Collyer, U. of Toronto Computing Services ]
			Fred