Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!csli!gandalf
From: gandalf@csli.Stanford.EDU (Juergen Wagner)
Newsgroups: comp.unix.questions
Subject: Re: Re^2: Unix deficiencies/problems
Message-ID: <8901@csli.Stanford.EDU>
Date: 10 May 89 02:18:19 GMT
References: <810038@hpsemc.HP.COM> <810049@hpsemc.HP.COM>
Sender: gandalf@csli.Stanford.EDU (Juergen Wagner)
Reply-To: gandalf@csli.stanford.edu (Juergen Wagner)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 23

Many UNIX systems support symbolic links, and that seems to be what we need
to implement system-independent file system structures. Symbolic links are
anchored in the file system, i.e. there is a pathname associated with them.

Programs should never refer to constant locations of files unless they can be
sure the respective files are always where they are supposed to be. In all
other cases, environment variables, command line arguments, or special
directives are a much better way of handling such differences. With symbolic
links, you get even more flexibility: your program can happily refer to files
wherever it wants, you only have to make sure that the links point to the right
files. This allows static naming a la FORTRAN (5 for input, 6 for output if
I remember that correctly) :-).

The desirable feature of not having global assignments to logical names
(= symbolic links) but to be able to change them from process to process
can be accomplished by using environment variables. It seems to me that
passing textual (uninterpreted) information through environment variables,
and leaving their interpretation to applications, is a cleaner way of
handling this subject than enforcing a single semantics all the time.

-- 
Juergen Wagner		   			gandalf@csli.stanford.edu
						 wagner@arisia.xerox.com