FATQW@USU.BITNET (Bryan Ford) (02/27/88)
How about this.
System: = Sys:System
T: = Sys:T
Clip: Devs:Clipboards
The best thing about this is you can redirect all of them without having
to redirect SYS:.
Also, maybe as just an idea to ponder. How about making things so you can
Assign a logical name to more than one directory? Then you could, say,
assign C: to RAM:C and SYS:C, or something like that. Then when you got
a directory of C:, you'd get both RAM:C and SYS:C. The only problem is if
you have two files of the same name in two directories bound together
this way...
Bryan
Bryan Ford //// A computer does what \\\\
Snail: 1790 East 1400 North //// you tell it to do, not \\\\
Logan, UT 84321 \\\X/// what you want it to do. \\\X///
Email: FATQW@USU.BITNET \XXX/ Murphy's Law Calendar 1986 \XXX/andy@cbmvax.UUCP (Andy Finkel) (03/04/88)
In article <8802270215.AA06588@jade.berkeley.edu> FATQW@USU.BITNET (Bryan Ford) writes: >Also, maybe as just an idea to ponder. How about making things so you can >Assign a logical name to more than one directory? Then you could, say, Assign names are just an external representation of a lock. We'd break programs big time if we tried to convert the lock list to a 2 dimensional list. Also, things would slow down considerably, as the system could have to search a bunch of directories before putting the 'not found' requester. Being able to specify C: and *mean* the one and only C: is a useful thing. The command path is meant to provide multiple lock style capability. Now, maybe what you actually mean is that we should have a device path and a library path. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
jesup@pawl20.pawl.rpi.edu (Randell E. Jesup) (03/04/88)
In article <3414@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >Now, maybe what you actually mean is that we should have a device >path and a library path. >andy finkel {ihnp4|seismo|allegra}!cbmvax!andy This is certainly worth consideration. For example, in the game I'm porting, I've had to first try to open the arp.library, then if it fails try to open it via a path (OpenLibrary("sub:libs/arp.library"...)). The ability to include a pathname to OpenLibrary (and probably OpenDevice) calls is less than well-known. I'm not totally convinced it's needed for libraries, handlers, and devices (yet), but I think I might be in the case of fonts. It is quite a pain to manage an immense font directory, especially if you want special- purpose sets of fonts for different programs. You could have OpenDiskFont search FONTS: and all other assigns beginning with FONTS (eg FONTS2:, FONTS_DPAINT:, etc). Maybe the rest of the answer (for fonts, at least) is to standardize on a font requester, that allows you to select style, size, etc AND lets you select what directory to look in them for (defaulting to FONTS:). Witness the problems with DPaint II and fonts. They just modified it so it no longer crashes if you have more than 17 fonts, now it only lets you select from the first 17! It should also let you ask to see what the current selection looks like. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (03/05/88)
In article <3414@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > Now, maybe what you actually mean is that we should have a device > path and a library path. Let's not stop there. Add to the list, a "cd" path, and an "operand" path (i.e., a file searching path). Any others? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
pds@quintus.UUCP (Peter Schachte) (03/08/88)
In article <23728@amdahl.uts.amdahl.com>, kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > In article <3414@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > > Now, maybe what you actually mean is that we should have a device > > path and a library path. > > Let's not stop there. Add to the list, a "cd" path, and an "operand" path > (i.e., a file searching path). > > Any others? Someone already mentioned fonts. One I sometimes want is an include path so I can put some of my includes in ram:. Perhaps another for shell scripts, if we're going to have to keep them separate (I like the way shell does this much better). If we ever get an extensible emacs, we'll need a path to search for emacs mock lisp (or whatever) files. SB-Prolog needs (and has) a path for the files it autoloads. It would be good to have a path for configuration files (every program seems to have its own idea where to find config files). Any program may want to search a path (or several!) to find files it needs to use. I think the path mechanism badly needs to be generalized, so that anyone can create a path, and it is easy for code to search a path for a file. That's why I believe assigns are the right place to do that: they're easy to set up and use. As for implementation: why is it so {hard | inefficient}? It would be easy to have a data structure struct pathelt { struct Lock *lock; struct char *name; struct pathelt *next; } An assign would point to one of these. When you go to open a file in a path assign, you first check the lock. If it's NULL, you lock the name and store it in lock. Then you use the lock and the file name just as you do now for an assign. If you don't find it, you repeat the process for next (unless next is NULL, in which case you fail). Ta Da. No problem. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds