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