geoff (10/24/82)
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 ]
Fredsjb (10/27/82)
If .* gives you . and .. from the shell, just use .[a-z]*
ken (10/27/82)
a simpler sequence to get to . files while avoiding . and .. is: ls .??*