Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds From: pds@quintus.UUCP (Peter Schachte) Newsgroups: comp.sys.amiga Subject: Re: The 1001 Paths Message-ID: <833@sandino.quintus.UUCP> Date: 29 Mar 88 02:04:38 GMT References: <4587@garfield.UUCP> <5489@well.UUCP> <850@nuchat.UUCP> <582@imagine.PAWL.RPI.EDU> Organization: Quintus Computer Systems, Mountain View, CA Lines: 85 Keywords: open Summary: No problem, and a variant proposal In article <582@imagine.PAWL.RPI.EDU>, jesup@pawl11.pawl.rpi.edu (Randell E. Jesup) writes: > In article <850@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >1> mount PATH: > >1> Assign C: PATH:df0:c!df1:c!ram:c > >1> list c: > >Directory "c:" on Thursday 23-Mar-00 > >df0:c Dir rwed Tuesday 06:19:29 > >df1:c Dir rwed Tuesday 06:19:29 > >ram:c Dir rwed Tuesday 06:19:29 > >3 directories - 1 block used > > What happens when someone opens c:filename for write if a) it exists in one > of the directories, b) exists in more than one, c) exists in none? I addressed this in a followup to Peter's posting: extend the proposal to allow users to explicitly specify which directory a file is to be written in if the user wants to open a file for output in a path. My suggestion was: 1> Assign C: PATH:df0:c!df1:c!ram:c#df0:c Given this, in cases a), b), and c), the file would be created in df0:c/. No problem. > What does one get back when one Examine()s the result of Lock("c:",...)? > Or when one ExNext()s it? Hmmm. I think you've pointed out a flaw in Peter's posting. I think the list c: command should print out all the contents of all the directories in the path, rather than the top-level directories. Then the behavior of Examine() and ExNext() should be clear. Isn't it? > Sorry, I'm afraid this will remain a fantasy. Why not just use shell > variables? I've said this before, but I'll say it again because I think it's important. The problem with shell variables is that they give the power to specify paths to the PROGRAMMER. If a given program doesn't EXPLICITLY have code to search a path, the program CANNOT be told to do so. Existing programs couldn't take advantage of a FONTS: path, or a C: path, or an INCLUDES: path, etc. This is a pointless and painful restriction. It often happens that a programmer doesn't envision all the uses his program will be put to, and as such, he may not see where paths will be useful. A path is just a generalized sort of directory. With a path assignment I'm just saying that FOO: is a pseudo-directory which always contains all the files in each of its constituent directories (except where the one file shadows another of the same name in a directory later in the path). It's really a simple, elegant concept. Shell variables don't allow this elegance. The implementation of assignments is immaterial to this argument. The reason assignments are the right way to implement paths, and shell variables are not, is that the SYNTAX for specifying a file name includes assignments, and doesn't include shell variables. If you fix Open() and Lock() to understand shell variables, they would be fine. But it is important that the specification of a path to search should be part of the FILE NAME, and not implicit in the program that tries to open the file. I have a proposal that is similar to Peter's, but might be a bit easier to implement (I'm not sure): 1> mount PATH: ; may not have to do this: addpath might be able to 1> addpath c ram:c, df0:c, df1:c createin df0:c 1> addpath fonts df0:fonts fontdisk: 1> assign c: path:c ; addpath should do this too, if possible 1> assign fonts: path:fonts ; ditto 1> list path: c Dir rwed Tuesday 06:19:29 fonts Dir rwed Tuesday 06:19:29 1> list path:c < all the files in ram:c, df0:c, and df1:c > 1> list c: < the same > The idea is that path: is sort of like a directory, but its top-level constituents are actual paths, and attempts to Open(), Lock(), Examine(), or ExNext() files there will search the path. Peter, what do you think? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds