Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!uunet!munnari!kre
From: kre@munnari.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <1781@munnari.oz>
Date: Fri, 14-Aug-87 16:55:57 EDT
Article-I.D.: munnari.1781
Posted: Fri Aug 14 16:55:57 1987
Date-Received: Sun, 16-Aug-87 09:38:30 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 45
Summary: Give up on this, its impossible to do correctly

I would have thought that this topic would have died a natural death by now,
but...

In article <2789@ulysses.homer.nj.att.com>,
ekrell@hector..UUCP (Eduardo Krell) writes:
> Doing it in the shell fixes the "cd /a/b; cd .." problem. But shouldn't
> "cat ../foo" be the same as "cd ..; cat foo" ?. Now, how are you going
> to do THAT in the shell?.

Perfectly true, that should work the same both ways.  There are just two
options I can see for making this (and other sensible expected semantics)
work in a consistent, repeatable, fashion.

Either adopt Doug Gwyn's suggestion, and replace the concept of a current
directory with the vms style path prefix - but as he said, that wouldn't
be unix any more.

Or leave the symlink semantics as they are in BSD (as Dennis designed
them) and stop pretending that they are links that happen to be able
to point across filesystems or to directories, and regard them as
fully fledged entities.  ("Leave them" applies to the path lookup
semantics wrt ".." etc.  As I have said before, I would modify some
of the other semantics a little, but all that is just gloss).

There's no intermediate representation that will work correctly (for
any reasonable definition of correctly) all the time.  And it doesn't
matter whether the faked semantics are implemented in the shell, or
in the kernel.  It doesn't work *consistently all the time*.

I'm fully aware of existing shell implementations (which are the easier
of the two to get close to right) and in normal everyday use the defects
quite probably are never going to appear (apart from the type mentioned
above, the problem that breaks these schemes can be demonstrated
without stepping outside the environment where the kludge is done,
ie: a shell implementation can be broken by a shell script that uses
nothing that isn't built into the shell, plus overhead glue .. which
might be built into some shells (test, echo, etc)).

It shouldn't be surprising to people that these things don't work,
kludges rarely do.  I'm going to leave it to people's imagination
to work out what the problem is (all you need to do is consider the
necessary features of any implementation, then use a brute force
method to bust that .. its not subtle).

kre