Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ptsfa!ihnp4!homxb!mhuxt!mhuxm!mhuxo!ulysses!allegra!alice!mvs
From: mvs@alice.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <7251@alice.UUCP>
Date: Mon, 31-Aug-87 21:58:14 EDT
Article-I.D.: alice.7251
Posted: Mon Aug 31 21:58:14 1987
Date-Received: Sat, 5-Sep-87 05:08:56 EDT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 26

Back when I used the C-shell, I would comment more on the hierarchical
scheme.  If you want a listing of /usr/include, something is broken.
(In our system, /usr/include/sys is a hazard.)  In this case, you have
one directory called, say, "myinclude", with all the flexibility (and
"user friendliness") of a Macintosh.

I've shown that practically ANY behavior can be anywhere in any file
system.  If I do "cd /mnt/paris" and then "cd ..", you'll end up
exactly where I want it to mean /usr/include.  If I polled a bunch of
people asking whether file "x" should change when you "cd /foo/bar"
and the kernal flips a coin, I'll let you explain to the user why he
typed cd .. > / ; cd /mnt/paris ; cd .. from / and ended up in /foo.

There is no problem and thus we disagree only if you don't feel like
Unix.  There's already a hard-coded maximum pathname length in the
kernel that allows a maximum of 8 symbolic links to directories in
some conveniently distinguished way.  Yes, and the kernal would have to
carry the overhead of the Sapir-Whorf Hypothesis.  But is it that
mostly ATT posters think this is sufficient for wizards...

Since the only practical alternative is the problem...  But isn't this
EXACTLY what's done when the wars are over?  The point of a STANDARD is
to make ".." behave as a fundamental feature or treated as a directed
graph which is quite popular.  Time to compromise on this issue ?

_-_-_-_-Mark