peter@sugar.uu.net (Peter da Silva) (10/20/88)
Alas, but Rico Mariani's PATH: device doesn't work for me as a replacement for the PATH kludge in AmigaDOS. (edit mountlist, install path-handler) 1> mount PATH: (system still up, a good sign!) I note that I can create normal subdirectories in PATH: as well as create files. It's still a fully functional RAM disk... a nice feature. (after creating path:s containing sys:s and sys:devs) 1> type path:s/mountlist (works fine) (after creating path:c containing sys:system, sys:bin, and sys:c) 1> path:c/ls Unable to load path:c/ls: stream name component invalid 1> assign c: path:c 1> ls Unable to load ls: Error code 210 1> why Unable to load why: Error code 210 1> sys:c/why Last command failed because stream name component invalid 1> sys:c/assign c: sys:c 1> why Last command did not set a return code (phew, at least I can get out of it) From the posting: > This is a mountable device driver that allows you to have search > paths for any directory, and those paths may include drive names as well as > volume names, thus fixing one of the most irritating limitations of the > AmigaDOS PATH command. Obviously I'm not doing something right. Any ideas? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
peter@sugar.uu.net (Peter da Silva) (10/20/88)
In article <2867@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > I note that I can create normal subdirectories in PATH: as well as create > files. It's still a fully functional RAM disk... a nice feature. An odd side-effect of this... I now have a disk named "Path Server" in my Browser window. Cute... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/21/88)
: :1> path:c/ls :Unable to load path:c/ls: stream name component invalid This caught me for about 5 minutes also... you need to create path:c containing: sys:system/ sys:bin/ sys:c/ sys: ... that tailing slash is required. I don't mind at all.. it makes the code smaller to just be able to concat the strings. you don't need a tailing slash for something that ends in a colon, of coures. -Matt
ricom@microsoft.UUCP (Rico Mariani) (10/21/88)
In article <2867@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Alas, but Rico Mariani's PATH: device doesn't work for me as a replacement for >the PATH kludge in AmigaDOS. > >(edit mountlist, install path-handler) >1> mount PATH: >(system still up, a good sign!) > >I note that I can create normal subdirectories in PATH: as well as create >files. It's still a fully functional RAM disk... a nice feature. > >(after creating path:s containing sys:s and sys:devs) Do you have the trailing / on the names in the path: device? You must have sys:s/ sys:devs/ In the file. Yes I know I could have tested to make sure that the path ended in a / and put one there if it didn't but then what about df0 should it become df0: or df0/. Or what if it's a virtual volume like My_fair_volume Then what? Do I add a : or a / ??? Well, I punted on the whole issue by insisting that there be a '/' at the end. Matt seems to have uncovered a possible startup problem in the path: device. So in order for things to work (until I fix it). Do a mount path: followed by cd path: and the startup will go well. Everything is fine from there, it's only a startup problem. Sorry but this is a use at your own risk release after all... -Rico
jlockhar@ssibbs.UUCP (John Lockhart) (10/22/88)
Is it possible to use the Path: setup for Fonts: instead? It would be
an advantage to keep fonts in several different places, and have them
all searched when necessary...
--
--- John Lockhart
___________________________________________________________________
...{mit-eddie,pyramid,datacube}!mirror!ssi3b1!ssibbs!jlockhar
jlockhar@ssibbs.UUCP or jwl@feanor.stanford.edupeter@sugar.uu.net (Peter da Silva) (10/25/88)
In article <20@ssibbs.UUCP>, jlockhar@ssibbs.UUCP (John Lockhart) writes: > Is it possible to use the Path: setup for Fonts: instead? It would be > an advantage to keep fonts in several different places, and have them > all searched when necessary... Not with the current version of PATH:, apparently. The docs claim that it doesn't support getting a directory of the PATH: device, which implies that Examine/ExNext isn't implemented. Waiting fervently (quick, gimme some Tylenol) for PATH II -- the revenge. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.
bjc@pollux.UUCP (Betty J. Clay) (10/30/88)
In article <20@ssibbs.UUCP> jlockhar@ssibbs.UUCP (John Lockhart) writes: >Is it possible to use the Path: setup for Fonts: instead? It would be >an advantage to keep fonts in several different places, and have them >all searched when necessary... > > >-- You can set a path to any font by putting the full path into the xxx.font (font header) file. You will then be prompted for the proper disk when the font is accessed. The easiest way to do this is with a little program written by Steven Vermeulen a few months ago. He called the program REN, and it was posted on Usenet at that time. Most BBSs will still have it. Betty Clay .........killer!pollux!bjc