Path: utzoo!lsuc!ncrcan!brambo!morgan From: morgan@brambo.UUCP (Morgan W. Jones) Newsgroups: comp.sys.amiga Subject: Re: REZ questions. Message-ID: <397@brambo.UUCP> Date: 21 Apr 88 04:55:36 GMT References: <8WOJNQy00VQFQHaEU7@andrew.cmu.edu> <28716@amdahl.uts.amdahl.com> Reply-To: morgan@brambo.UUCP (Morgan W. Jones) Organization: Bramalea Software Inc., Bramalea, Ont. Lines: 51 In article <28716@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: >First, picked a pure and shareable command (ARP's info), and made sure there >was no copy anywhere in my path, and took it off the rez list. Tried issuing >"info" (just to be sure), and got "command not found", as expected. Put a >floppy in df0:, and cd'd to the directory with "info" in it. Did a "rez -l info", >and noted that the file seemed to load. Cd'd to my "home" directory in vd0:, >removed the floppy, and entered "info". Got the usual "info" output, without >any problems. This is what I (and I think, you) expect "rez -l" to do, right? Actually, the person who said that it requires the disk to be in the drive is correct. Since REZ only replaces the vectors for LoadSeg and UnLoadSeg, it doesn't know that you are trying to load a program until the CLI actually tries to load the file. Thus when you type "info", the CLI checks the path to convert "info" to "C:info" and then does a LoadSeg("C:info"). The reason that you didn't get a file requestor asking you to insert a volume is because the CLI (or whatever) actually caches the path name of the last few commands executed - so it knows the pathname of the command without having to try for a lock (if that's what it does) on "C:info" and "ram:info" etc. to determine which, if any, directory it is in. If you had executed several other commands on a different disk and then tried "info" with the disk removed, you indeed would have seen the requestor asking you to insert the volume that contains C:. After playing around with REZ, I find it a really inspired piece of code, but not quite complete enough to be a useful tool. The two problems that struck me were that REZ didn't use the PATH to determine where commands are (easily fixed), and that the disk containing the command has to be inserted in a drive which makes it next to useless on a floppy based system with a meg or more. I can see two ways to solve this second problem: rez adds ram:rez.stubs to the path, and every time that a command is made resident an empty file is created in rez.stubs under the same name, the file being deleted when the program is made unresident; the better alternative is to add a device REZ:, which is added to the path - whenever it is asked if a file is in it it responds yes if the file is resident and no otherwise - and so whenever a resident command is asked for by the CLI it will actually try to load REZ:command. This second approach also has the advantage of allowing data files to be made resident (particularly useful for libraries like c.lib). And if you get to this point in my message, I appologize for the long paragraphs but I couldn't see a good place to break them, and at 11:54 at night I'm not about to restructure them. >/kim -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."