Path: utzoo!attcan!uunet!super!udel!princeton!njin!rutgers!mailrus!wasatch!cs.utexas.edu!sm.unisys.com!csun!solaria!ecphssrw From: ecphssrw@solaria.csun.edu (Stephen Walton) Newsgroups: comp.sys.amiga Subject: Re: path: & 1.3 (also RAD: recovering) Message-ID: <385@solaria.csun.edu> Date: 30 Nov 88 22:22:57 GMT References: <284@gtss.UUCP> Reply-To: ecphssrw@trantor.csun.edu (Stephen R. Walton) Distribution: na Organization: California State University, Northridge Lines: 61 In article <284@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: (a great deal of stuff deleted, then Charles asks about the PATH: handler) > Suppose I have created a file in path: called "c" containing the following > lines: > > sys:c/ > fred:c/ > barbarella:c/ > > and have done something like 'assign c: path:c' or even > 'path reset path:c'. Apparently, the PATH: device first checks on the > existence of its entries, one by one, Charles then points out that path: asks first for fred:, then for barbarella:, then for fred: again (first request to see if fred:c exists, second to find the command in it). I agree that this shouldn't happen, but in the long run, I think you'll be happier if you simply make path:c read: sys:c/ rad:c/ df0:c/ df1:c/ (or something similar) which will then search the mounted drives and no others. You'll still get a requester if there is no floppy at all in df0: and/or df1:, but I think that is rarely the case. > After putting path:c in my command path (via 'assign c: path:c' or > say 'path reset path:c'), often (perhaps always) when I try to execute > the 1.3 command 'more' (which is pure but which I have not made > resident) I am visited by the GURU Hmm, I *think* I've used more with path-handler installed without trouble, but I'll check. ... OK, I'm back (ah the joys of multitasking). I just used the 1.3 More when More was in sys:C without trouble. I did a PATH RESET, and an ASSIGN C: PATH:C with PATH:C being the above file, and More S:Startup-Sequence went without trouble. Conman and WShell in use. I have used PATH: on several other occasions, without any trouble, under most 1.3 Omegas and the release. >This is under 1.3 Kickstart on an Amiga 1000 with a Michigan Insider. This is why RAD: doesn't recover. No recoverable RAM disk can survive in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for its existence. Only true FAST RAM will work. Possible commercial announcement: Bill Hawes says over on BIX that he has finished a similar Path-Handler which will come with the next update of WShell. It allows you to simply say: Assign C: Sys:c,df0:c,df1:c (for example). You can also do a Dir C: with his handler, and get the result you expect, rather than an infinite stream of "Unknown Packet" errors. -- Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge RCKG01M@CALSTATE.BITNET ecphssrw@afws.csun.edu swalton@solar.stanford.edu ...!csun!afws.csun.edu!bcphssrw