Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!sunybcs!bingvaxu!leah!uwmcsd1!uwmacc!hobbes!root From: root@hobbes.UUCP (John Plocher) Newsgroups: comp.unix.wizards Subject: Re: Symbolic Links Message-ID: <197@hobbes.UUCP> Date: Wed, 31-Dec-69 18:59:59 EDT Article-I.D.: hobbes.197 Posted: Wed Dec 31 18:59:59 1969 Date-Received: Thu, 27-Aug-87 07:04:04 EDT References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2838@ulysses.homer.nj.att.com> <1793@munnari.oz> <2854@ulysses.homer.nj.att.com> Reply-To: root@hobbes.UUCP (John Plocher) Followup-To: comp.unix.wizards Organization: U of Wisconsin - Madison Spanish Department Lines: 60 +---- Eduardo Krell writes in <2854@ulysses.homer.nj.att.com> ---- | This is really getting annoying ... Yup | This is easy. Nope | The intention is to make ".." behave as a logical operator. This means that | | 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. | | 2: if I find a ".." in a pathname, it refers to the logical parent, | not the physical one. Thus, while in /usr/include/sys, "ls .." will produce | a directory listing of /usr/include. What about a C program which does a #include ? What if the file itself does a #include "../foobarboop.h" ? All this works if and only if the C compiler references things as "/usr/include" + filename in <>'s" 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. 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! 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. If this still confuses you, well, MS-DOS doesn't have links and so doesn't have this problem. Use that :-))) The point is, links AS THEY ARE NOW are very useful 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. There is method behind the madness of the way links work; if you don't understand this, study it some more. Use pushd and popd. Make some aliases (like cd) which do what you want. Spend an afternoon customizing your environment like this and it will be an afternoon well spent. Just don't "break" the deterministic behavior of links for *me*. | >However, this all started with a proposal to move these semantics into the | >kernel | You can't achieve 2: above unless it's done in the kernel. I don't want 2: and 1: can be done with aliases (or whatever) in *your* shell. -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU