Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!tektronix!orca!tekecs!doghouse!snoopy
From: snoopy@doghouse.gwd.tek.com (Snoopy)
Newsgroups: comp.unix.wizards
Subject: Re: symbolic links are a botch
Message-ID: <8738@tekecs.TEK.COM>
Date: Thu, 18-Jun-87 15:03:14 EDT
Article-I.D.: tekecs.8738
Posted: Thu Jun 18 15:03:14 1987
Date-Received: Sun, 21-Jun-87 17:31:56 EDT
References: <2629@ulysses.homer.nj.att.com> <390@murphy.UUCP> <898@rtech.UUCP> <8689@tekecs.TEK.COM> <912@rtech.UUCP>
Sender: nobody@tekecs.TEK.COM
Reply-To: snoopy@doghouse.gwd.tek.com (Snoopy)
Organization: The Daisy Hill Puppy Farm
Lines: 72

In article <912@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes:

>>	"Everything is a file."

>Repeating that everything is a file, whether or not it is true, is not
>a useful exercise.  A terminal is a file, but I can't seek on it;
>a (vanilla) pipe is a file, but I can neither seek on it nor name it;
>/etc/passwd is a file, but I can't mount it; the swap partition is a file,
>but I can't put it into cbreak mode; and so on.

There is a difference between saying "You can't because it is impossible"
and saying "You can't because I won't let you."  One of the big wins in
Unix is that it doesn't put up artificial restrictions.

>>Yes, the "cd .." and "pwd" stuff can get a bit confusing.... How about
>>adding options to cd and pwd (and whatever) to specify going up rather
>>than back?  [yeah, I know, Yet Another Option :-( ]  Sometimes it would
>>be handy to get pwd to tell you both paths.

>In general, having turned the name space into a dag (graphs with cycles,
>not being well-formed name spaces, are not considered), there may be more
>than two ways "up;" "pwd" could output arbitrarily many paths.

I'm think of having the shell remember how you got somewhere, and having
a built-in pwd tell you how you got there (using the symlink names),
while "pwd -L" (or "/bin/pwd" ?) would give the "real" path.  There
could be many possible paths through symbolic links to get there,
but you only got there one way, so there is only one symbolic link
path to print out.

Guy Harris writes:

| Disallowing symbolic links to nonexistent files - or, in fact, doing
| ANY checking of the contents of the symbolic link - would tick off a
| lot of people.  For example, I think the ISIS user-level distributed
| file system library supports symbolic links to remote files; the
| syntax for remote files is some sort of "host:pathname" syntax.

I don't know about ISIS, but with DFS I can say

	ln -s //machine/usr/foo/src/bar/RCS RCS
	make bar

and *presto*, everything works.  Very nice!

| Symbolic links to directories may be a pain, but it's a pain we'll
| have to live with unless we forbid symbolic links completely.

Or until we figure out how to deal with them properly.  A surprising
number of utilities need to know about the existance of symlinks.
A lot of the problems with symlinks is that various utilities don't
support them properly.  For example, what does your ls do when you
say "ls -lFL" for a symlink pointing at non-existant file? Mine does:

??????????  ? ????????        ? ???  ? ??:?? foo <- bar@?

What else can it do?  The info it wants to print isn't there.

Chris Torek writes:  (from the /dev/stdin discussion)

} One of the wonderful things about Unix is its simple naming scheme.
} Everything is a file.  Want to see a file?  `cat foo'.  Want to
} see a directory? `cat .'.  Want to see what is on a tape?  `cat
} /dev/tape/rdefault' [*].  In V8 processes became files, through
} /proc.  This is the right way to go.

Hey, does this mean I could have a symlink to a process??
(If I had v8)  Cosmic!

Snoopy					Unnecessary restrictions?
tektronix!doghouse.gwd!snoopy		     Just say NO!
snoopy@doghouse.gwd.tek.com