Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!uflorida!gatech!gtss!chas
From: chas@gtss.UUCP (Charles Cleveland)
Newsgroups: comp.sys.amiga
Subject: path: & 1.3
Message-ID: <284@gtss.UUCP>
Date: 30 Nov 88 00:51:42 GMT
Reply-To: chas@gtss.UUCP (Charles Cleveland)
Distribution: na
Organization: Georgia Tech School of Physics
Lines: 78

I have recently gotten the 1.3 Enhancer.  While trying to figure out how
to fit another recent acquistion, Lattice 5.0, onto a reasonable number of
floppys & ram:things (memory is limited, and there ain't no hard drive yet)
in a way that would make it the most convenient to work in the usual cases,
while still handling the more obscure ones on the fly, I had the idea of
trying the recently posted (comp.sys.amiga.binaries/sources) PATH: device, so
that I could split the LIB: directory between reasonably likely libraries (on
RAD:) and the occasionally useful ones (on floppy).  Lattice 5.0 libs have now
proliferated (what between 16 int libs and 32 bit ones, and ones that use
registers to pass some arguments and those that don't, etc., all roughly
equivalent and about the same size) to the point that cramming them all into
memory when I only need a few is painful, while I would much prefer for the
system to find the oddball request of mine instead of having to make massive
readustments just because I want to have a quick look a something that requires
special treatment.  So I thought PATH: would let me put the more used entries
in RAD: and leave the rarely used ones on floppy and have the best of all
possible worlds.

And perhaps it will.

However, it was natural to first introduce the sort of example in the PATH:
device documentation, such as constructing a command path and then using it
to to find requested commands, instead of just using the PATH command.

:-( Problem the lesser:
     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, and only then tries to actually find
     the file in question.  Suppose in my case that there are no drives other
     than df0: and df1:, df0: contains sys: and is sancrosanct, and df1:
     contains barbarella: at the time I try to execute a command in
     barbarella:c.  Without using df0:, I am faced with a succession of
     requestors, first for fred:c, to make sure it exists, and then for
     barbarella: to make sure it exists, and then for fred: again, to try to
     find the command in it, and finally for barbarella:, to try (sucessfully
     at last), to find the command.  It would seem preferable, after first
     determining that fred:c exists to then search it for the command, and
     only then determine whether barbarella: exists and then search it for
     the command (sucessfully, and with only half the swaps).  Of course,
     the path command checks for existence only on its execution, which is
     even better, but a little harder for something like PATH: to handle.
     Obviously I think that at a minimum PATH: should change the order of
     doing things, and search a member for the target immediately after
     having verified its existence, instead of verifying all members existence
     before searching any for the target.

:-( Problem the greater:
     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, with the accompanying loss of
     RAD: on reboot (which lives in C00000 on my machine, give or take a 0).
     I would try to determine the precise GURU number now, except for not
     being able to complete this message.  Multitasking has its limits.

This is under 1.3 Kickstart on an Amiga 1000 with a Michigan Insider.
ARP is nowhere to be seen (except on other disks where I have seen odd
behavior after trying to bring up the 1.3 shell).  ConMan is in use on
all these disks.

So has any one else seen any odd interactions between PATH: and 1.3, at any
level of the gamma releases?  (I would like to think that Lattice actually
included the 1.3 release stuff on their disks, since otherwise they included
a lot of 1.3 gamma.  I can't say that I've copied over all their l:,
libs:, etc. directories with my 1.3 release, though perhaps I should.  Or
perhaps I shouldn't.)
-- 
-  It is better for civilization to be going down the drain than to be  -
-  coming up it.                                        -- Henry Allen  -
Charles Cleveland  Georgia Tech School of Physics  Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas          INTERNET:  chas@ss.physics.gatech.edu