Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!kre
From: kre@munnari.oz (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <1793@munnari.oz>
Date: Sun, 23-Aug-87 07:42:20 EDT
Article-I.D.: munnari.1793
Posted: Sun Aug 23 07:42:20 1987
Date-Received: Sun, 23-Aug-87 22:22:32 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2838@ulysses.homer.nj.att.com>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 80

I suspect that 99% of the population have gotten bored with this by now,
so this is going to be the last I say on the subject, but, one last time...

In article <2838@ulysses.homer.nj.att.com>,
ekrell@hector..UUCP (Eduardo Krell) writes:
> What you're saying is that there is no problem and thus we disagree.

No, not quite, not "no problem", just a different problem.  This
is the problem...

> How many system administrators out there have had
> to explain this to new Unix users?

The problem isn't that it needs to be explained, the way the system
is set up at the minute, with everything attempting to give the
impression that symlinks are invisible objects, explanations are
going to be required.

The problem is that people conclude from this that the right thing
to do is change the semantics into something just about impossible
to explain so that its necessary to explain less often.

> If you take a poll asking people where they would expect to be after
> doing "cd /usr/include/sys; cd ..", I would bet a large majority to
> answer "/usr/include".

Without more knowledge of what's going on, and with a background of
unix experienc, you're probably right.  If I polled a bunch of people
I pulled off the street, I doubt that many would answer at all.  If
those people were educated about unix with knowledge of symlinks from
the start, and with the knowledge that they aren't invisible, then the
answer to a later poll might be different than you expect.

If you took a poll of people asking whether file "x" should change
when you alter file "y", how many do you think would say yes?  Of
course we all know about links already, but they are confusing, and
most new users usually need to have them explained.  Let's get rid
of links...

> If the system
> behaves in a way that's different from what most people expect, then it's
> broken as far as I'm concerned.

All kinds of real things don't behave the way most people expect.
They're not all "broken".

> When I do a "cd /a/b" and end up in a different directory, say, /c/d,
> then the symbolic link IS equivalent to the directory it points to.
> Once I "cd" to that directory, I get to the same i-node as /c/d.
> That qualifies as being equivalent, I would say.

If they're equivalent, then "cd .." after either should have the
same effect, otherwise they can't possibly be equivalent, surely?

If we're there in /c/d (a path without symlinks, as obtained from /bin/pwd)
and you do a "cd ..", where should we go?  I say wherever ".." points,
usually "/c", in all cases.  Simple, and consistent.  It does require
some education about the properties of symlinks.

You say "/a" if the path used initially was "/a/b".  Seems simple
too?  But is it really?  Do you want to be in "/a" if "b" was ".." ?
Probably not, so now the rule is "/a" unless "b" is "..", and in
that case something else, depending on what "a" was, and potentially
on previous history.  How about where "b" is "."?  There are
looking to be a bunch of special cases here, which is starting to
get a bit messy isn't it?

And none of this overcomes the problems with actually implementing it
and making it work properly, assuming that you can actually produce
a nice clean definition of what you're trying to implement.

Let's just leave symlinks basically alone.  I don't mind if people
want to use shells that have magic cd commands that attempt to guess
what you intended to do .. if it gets it right most of the time for you,
then great, being able to use any shell that suits you is one of the
advantages of unix.  However, this all started with a proposal to move
these semantics into the kernel, forcing them on everyone, assuming
that an implementation is possible.  That would be a disaster.

kre