Path: utzoo!attcan!uunet!ginosko!uakari.primate.wisc.edu!ctrsol!cica!iuvax!rutgers!att!cbnewsc!gregg
From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Want multiple default directories
Message-ID: <3495@cbnewsc.ATT.COM>
Date: 27 Sep 89 14:01:20 GMT
References: <780@lpami.wimsey.bc.ca>
Organization: AT&T Bell Laboratories
Lines: 65

The way that VMS does this seems to be the most logical.  Following in the
steps of TOPS-10, VMS allows the following.

	1.  Process private logical names
	2.  Job private logical names
	3.  Group wide logical names
	4.  System wide logical names

1) Allows a process to store things in logical names or to receive parameters,
such as filenames, in logical names.

2) Allows all related processes to share a logical name.  This is used to
   either minimized copies (the job table is shared while the process table
   is copied per process) of the table or allow mulitple processes of a
   single "job" to share/exchange information, such as filenames.

3) A group refers to a users login identity.  A group table is typically
   used to give a group of users access to something without all users
   having to either have the information or know how to get to it.  Things
   in a group logical table are usually root directories of packages that
   one particular group of users are interested in.

4) System logicals are for use by all users.  They contain things like which
   disks contain the roots of which directory structures etc.

Now, any of these logical name classes may contain a comma separated string
of directories when used in the context of a filename.  For example, I am
using TeX to write a document, and I have some private macros that I want
TeX to load with my document.  If I use a filename of the form,

	TEX$INCLUDES:mymac

and TEX$INCLUDES was defined as

	define TEX$INCLUDES MY$HOME:[TEX.MACROS],TEX$ROOT:[MACROS]

The file open request would search each of those directories and return
a handle to the first file found.  The translation is recursive so that
TEX$ROOT could be defined in the system table, and MY$HOME in the job
table (the translation of logical names starts at 1 above and moves
towards 4, looking for a definition).

Open for read requests return the first file found.  Open for write
requests return the first file found unless the file does not exist
in which case the first directory in the list is where the file is
created.  This is not so bad given the above ordering of directories.

In VMS this comes in most handy in the multi-machine cluster where several
machines share the use of a package, but also have site specific files
for that package (executables verses configuration scripts are a good
example).

For Amiga-Dos, per-icon INFO would equate to process or job logicals.
There is no group simularity, and system logicals are already implemented.

Having opens look through a list could be implemented as a
library routine that sets in front of the standard open.  That way,
executable open requests would be rewritten as opens for PATH:progname in
the exec code.  Presto, each icon can have its own PATH and not interfere
with others.  If I want a particular package to be able to make use of
its own private library of programs, I don't have to have a global PATH
that holds everything.
-- 
-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)