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