Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdahl!kim From: kim@amdahl.uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga Subject: Re: REZ questions. Message-ID: <28716@amdahl.uts.amdahl.com> Date: 18 Apr 88 09:20:26 GMT References: , <8WOJNQy00VQFQHaEU7@andrew.cmu.edu> Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 95 Summary: some experiments, and possibly the cause ... In article <8WOJNQy00VQFQHaEU7@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > If you are going to keep the commands in vd0: why bother having REZ around in > the first place? I realize you are merely evaulating REZ, but it seems > pointless to have two copies of a program around in memory so that you can only > execute one of them. If that were the solution I were looking for, I would > simply copy a batch of commands to ram:c and say "path add ram:c". I was simply explaining why I might not have seen the problem you describe. I certainly wasn't suggesting it as a solution. I've no intention of having things I make resident in vd0: as well (eventually), but before I go to the (considerable) trouble of reorganizing my normal environment, I want to be fairly sure that such a major change isn't going to give me a headache later on. > Using -l was the very first thing I tried. Remember, my goal is to not require > the Workbench disk in my only disk drive during normal use. Mine too! I just tried a couple quick experiments ... 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? Second, tried something (arc) that was neither pure, nor sharable. Following the same methodology as above, I got a little different results (but no file requesters, or such). Once "arc" had been loaded ("rez -l arc"), I entered the command "arc", to get the arc's familier instructions. If the floppy(s) in the drives were NOT the floppy I loaded arc from (or if the drives were empty), I got the instructions after a short pause (while a working copy was made from the resident area, I presume ... just as if arc had been in vd0: or ram:). If however, the floppy I'd loaded arc from was in either drive (it had previously been removed, so there was nothing in any of Facc's buffers, etc.), the drive was accessed briefly (only a second, or so ... far less time than is needed to load/copy arc), then out came arc's instructions on the screen. Hmmmmm ...? Tried one other thing with arc ... pop'd another CLI window open, and tried issuing "arc" from two CLI's nearly simultaneously (remenber arc is marked not sharable). On one attempt, I got the familier instructions in one CLI, while in the other I got "command not found". On another try, I got the instructions in both CLI's, with the 2nd invocation waiting for the 1st to finish. Sounds like some timing sensitivities in rez's code, but at least both outcomes were benign. In any case, nothing ever put up a requester, etc. Which is not to say you'll have similar results (in fact you're not, since you are getting one). I also tried fooling around with my assigns and path a little, but never could get a request for WB, or any floppy ... One final thought just occurred to me, that I just verified ... if you aren't cd'd to the directory that the commands reside in when you issue the "rez -l" command(s), rez prints a "couldn't find" message, but also puts the command(s) on the rez list (as if you had issued "rez -a ..."). I.e., when "loading", rez doesn't look down your path, but only in the current directory. Then, if your c: dir is still assigned to WB:c, you might well get a requester the 1st time you issue a command. And you don't see the "couldn't find" message, because you redirected them to nil: ... Try cd'ing to where your commands are before issuing your rez command(s), and see if that doesn't fix the problem. (DON'T try something like "rez -l c:foo", as Jim warns against that ... and it doesn't work, anyway). > If REZ had worked the way I had expected it to, I would be more than happy to > blow off the BCPL junk and go with ARP. If you experiment a bit, I think you can get rez to work the way you'd expect it to. BTW, all the ARP stuff I've tried is both pure and sharable. > Are there any other suggestions? Does anybody know about the other "resident" > options (especially the one that's supposed to come with 1.3)? The ARP release (v1.1) has a resident command also. Haven't tried it myself, as I've been told by someone who has tried it, that rez works much better. Then there is Bill Hawes' "resi", which comes with his WShell, but I haven't tried it either. BTW, he's said he'll fix WShell to support whatever resident method becomes most popular. Hope you can find something of value in all of this ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25