Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!rti!trt
From: trt@rti.UUCP (Thomas Truscott)
Newsgroups: comp.unix.wizards
Subject: Re: /bin/test and stat(2)
Message-ID: <1796@rti.UUCP>
Date: Thu, 15-Oct-87 19:47:14 EDT
Article-I.D.: rti.1796
Posted: Thu Oct 15 19:47:14 1987
Date-Received: Sat, 17-Oct-87 10:24:42 EDT
References: <9721@brl-adm.ARPA> <1849@munnari.oz> <6555@brl-smoke.ARPA> <6565@brl-smoke.ARPA>
Organization: Research Triangle Institute, RTP, NC
Lines: 62
Summary: "", ".", and ".." just aren't fun anymore

In article <6565@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <3283@uw-june.UUCP> ka@uw-june.UUCP (Kenneth Almquist) writes:
> >	mkdir junk;  cd junk;  rmdir ../junk
> >	ls .
> >This will tell you that "." does not exist ...
>...
>This doesn't seem to have any bearing on the "" vs. "." issue.

Of course it has bearing!  The (side) issue is:
is "" or "." more properly the name of the process' working directory?
The answer is "" (on systems that do not reject it)
as there are cases where the directory entry "." is inaccessible.

Here are some other arguments we have heard:

    "Do you ever see the ``zero length strength'' named file
    in a directory?  No, you don't." (Roberts)

Do you ever see the ``/'' named file in a directory?

    "... why should there be two ways to refer to the same
    thing (the current directory)?  It really doesn't make sense!" (Lonigro)

It is true that "/" is "/." is "/./." is "/tmp/.."
but it would be painful to disallow "." and ".." in pathnames.

    "It does have the drawback that it doesn't behave right under string
    concatenation etc., and it was eventually outlawed (probably in response
    to naive-user complaints) in the official AT&T releases of UNIX." (Gwyn)

I agree.  The "" pathname was outlawed
not (1) to avoid the oft-cited anomaly in concat(dir, "/", component) but
rather (2) to help programmers who use uninitialized or unchecked values.
Note that concat(uninitialized_value, "/", component) is a program bug,
not The Anomaly, and disallowing "" as a pathname may not fix the bug.
Face it, outlawing "" is like outlawing filenames with whitespace in them,
both are justifiable but both are blemishes in the Great Plan.

DOT AND DOT-DOT IN THE UTILITARIAN UNIX SOCIETY
We have learned that "" has no role in UNIX of the future,
but what of "." and ".."?  In days of yore they were simple
directory entries and the kernel paid them no special attention.
As Ken Thompson put it, the notions of working
and parent directories "just fell out" of the mknod system call.
But mknod, though elegant, lacked utility
(perhaps because it, like creat, lacked a final "e").

And so the kernel came to watch over the dot and the dot-dot.
The foremost concern was for the keepers of the mount points,
but anon came mkdir and rmdir and then the systems opened.
At its highest manifestation (NFS) the incantations of ".." and '.'
verily reverberate through the great pathways of the kernel.

And now we see that the kernel pays so much attention
to the semantics of the dot and the dot-dot
that the actual directory entries are once again
paid no special attention.
So I suggest that we banish "." and ".." in the
filesystem of the future and make them as the "/",
invisible spirits to be called from the vasty deep.

	Tom Truscott