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: <1804@munnari.oz>
Date: Mon, 31-Aug-87 08:45:01 EDT
Article-I.D.: munnari.1804
Posted: Mon Aug 31 08:45:01 1987
Date-Received: Tue, 1-Sep-87 05:40:15 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2878@ulysses.homer.nj.att.com>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 78
Summary: I really was going to keep quiet...

One thing that's being ignored here is that the interpretation of
".." (if you want it to be a variable, or context sensitive thing)
that should apply is that which applied when the ".." was created,
not the one that happens to be current when the ".." is interpreted.

You can argue that

	cd /usr/include/sys; cd ..

should put you in /usr/include, and there's a certain superficial
attractiveness to this.

However, if I do

	cd /usr/include/sys; ln -s ../../bin bin 

I can then (I presume) do

	cd bin

and I end up in /usr/bin if all is going well, and the context
sensitive interpretation applies.

Now, sometime later, I tell you that you can get to /usr/bin
from /usr/include/sys by just using "cd bin" so you decide to
try it ...

	cd /sys/h (you're not silly, you know where /usr/include/sys
		   really lives, and its much less typing)
	cd bin

and you find yourself in /bin .. not exactly what was promised at all.

The way to fix this is to make the interpretation of ".." depend on
the current context of the user who planted the reference to "..",
this will also solve all the problems of uses of ".." implanted in
C source, in shell scripts, and just about anywhere else that you
might want to look, which will all break if you change the semantics
of ".." in any way other than this.

And yes, I admit, ".." at a mount point is a special case, and changing
the mount point will break any referenes to ".." that happen to pass
back through it.  However, this is a system administrator activity,
something that is rarely done, and is only done by people expected to
be responsible for their actions, any random user can't make this change
just because he feels like it.

This is, incidentally, the same problem as the use of SHELL in the
Sys V "make", where the shell that should be used is the one that
the Makefile writer planned, whereas the one used is that of the
user running make.  Of course the Makefile writer could have planned
for this, and explicitly set SHELL, but if that's required, what's
the point of importing SHELL at all, ever?

The same is true of the system(3) routine in libc (on all versions
of unix I think).  Except here which shell to use depends on where
the arg to system came from ... system("foo bar ...") should use the
programmer's shell (or the one he plans on when he wrote the program)
whereas system(gets(buf)) should use the user's shell.

Why not just accept that these questions are really hard to get right,
and the fewer of them we need to get right, the better.

As someone else said, the more "user options" there are the harder
it is to get anything done right at all.

In the case of ".." the solution is quite simple, leave the path
interpretation semantics the bsd way, no options, no per user
interpretation, and simply accept that

	cd /usr/include/sys; cd ..

puts you in /sys (wherever that happens to be) rather than /usr/include.

If System V can't have symbolic links without changing the semantics,
then lets just keep System V without symbolic links at all.

kre