Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!bellcore!faline!ulysses!hector!ekrell
From: ekrell@hector..UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <2877@ulysses.homer.nj.att.com>
Date: Wed, 26-Aug-87 23:25:27 EDT
Article-I.D.: ulysses.2877
Posted: Wed Aug 26 23:25:27 1987
Date-Received: Sat, 29-Aug-87 06:03:22 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: ekrell@ulysses (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 83

In article <197@hobbes.UUCP> root@hobbes.UUCP (John Plocher) writes:

>| 1: if I do "cd /usr/include/sys" and then "cd ..", I end up in /usr/include
>|    no matter what.
>
>So write (or build in) a new cd command which does this.  I'm not stopping
>*you* from doing it.  Just don't force *me* to use it, thank you.

I don't need to write a cd command. ksh already does it for me, thanks Dave!

>What about a C program which does a #include <sys/foobar.h>?  What if the
>file <sys/foobar.h> itself does a #include "../foobarboop.h" ?  All this 
>works if and only if the C compiler references things as "/usr/include" +
>filename in <>'s"

First of all, I just went thru all the files in /usr/include/sys under System
V Release 3 and there is no #include "../<anything>".
There are some in BSD 4.3 in the form #include "../machine/foo.h" which
should really be #include <machine/foo.h>.

>  Now I am recompiling the kernal, and its source is in the directory
>/sys/src.  There is a subdirectory here called sys which is a link to the
>directory known above as /usr/include/sys.  The $68K question is "What file
>does "../foobarboop" reference now?"  If it isn't the SAME ONE as referenced
>in the first case, something is broken.  period.

In our system, /usr/include/sys is a symbolic link to /sys/h. If a cd to
/usr/include/sys, I can do "ls" and see all the header files. If I do "ls ..",
I don't get /usr/include.
If I do "cd /usr/include/sys" and then "ls ..", if I don't get the contents
of /usr/include, something is broken, period.

>  This is the difference between a deterministic method (what we have now) and
>a nondeterministic one (what is proposed).  I'll take the former any day!

nondeterministic is a bad name. It's 100% deterministic, you tell me how
you got there and I'll tell you what ".." means. It's not a physical link
anymore but that has nothing to do with nondeterminism.

>My solution:
>  When in /usr/include/sys, and you want a listing of /usr/include, do a
>ls .., and when you want a listing of /sys/src, do a ls /sys/src.  If you
>get confused easily, the first case can be expanded to ls /usr/include.

The problem is /usr/include/sys is a symbolic link to /sys/h. If I do ls ..,
I don't get /usr/include !!! That's the problem.

>The point is, links AS THEY ARE NOW are very useful

and they are much more useful (at least to me) if .. is treated as a logical
operator.

> and, two, links to directories destroy the "tree" structure
>of the filesystem.  Links turn it back into a directed graph which is
>not easy to understand if you try to use the "tree" mentality on it.

I know links to directories destroy the tree structure. Now, the questions
is: provided we don't have tree structure anymore, what's the next best thing?

>There is method behind the madness of the way links work; if you don't
>understand this, study it some more.

I don't need to study anything. I understand how symbolic links work.
In fact, I've added symbolic links to our experimental version of System V,
so don't think I'm a naive user. The problem is I find it very hard to
justify that if a do a cd /usr/include/sys, then .. can be anywhere in
any file system. I want it to mean /usr/include.

>Just don't "break" the deterministic behavior of links for *me*.

I am not introducing nondeterminism. If you "cd /foo/bar" and the "cd .."
you'll ALWAYS end up in /foo. ALWAYS, no expections. In your system, you might get
to /foo or you might get someplace else, depending on whether /foo/bar was
a symbolic link or not. I'll call that nondeterminism to some degree.

>I don't want 2: and 1: can be done with aliases (or whatever) in *your* shell.

1: is already done in ksh. 2: is needed to keep "ls .." and "cd ..; ls"
consistent given we already have 1:.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {ihnp4,seismo,ucbvax}!ulysses!ekrell