Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpihoah!hpirs!hpisoa1!davel
From: davel@hpisoa1.HP.COM (Dave Lennert)
Newsgroups: comp.unix.wizards
Subject: Re: symbolic links are a botch
Message-ID: <2200015@hpisoa1.HP.COM>
Date: Sun, 7-Jun-87 18:37:17 EDT
Article-I.D.: hpisoa1.2200015
Posted: Sun Jun  7 18:37:17 1987
Date-Received: Thu, 11-Jun-87 06:34:30 EDT
References: <2629@ulysses.homer.nj.att.com>
Organization: Hewlett Packard, Cupertino
Lines: 20

One problem with making ".." an operator and retrace the symbolic link 
path rather than the "hard link" path is that, if you cd to a directory
via a symbolic link and then proceed to compile some C source which does
a #include "../foo/bar.h", then you may not find the same (or any) include
file.

Similar problems arise with tags files.

Such a context sensitive interpretation of ".." would make it impossible
to reliably setup such things.

Symbolic links are mainly a facility to get around certain unix limitations
such as:  you can only mount a file system at one mount point at a time (and
hence all the disk space has to be used in one file subtree).  It allows
programs with hardcoded pathnames to traverse (one-way) and get to files 
even when the sysops need to place the files elsewhere.

I applaud what you're trying to do, though.

-Dave Lennert   HP   ihnp4!hplabs!hpda!davel