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)