ajbrouw@neabbs.UUCP (ALBERT-JAN BROUWER) (11/13/89)
(Sorry, newsfeed shouts names) In a reply to the 1.4 beep request Fred Gilham writes: > Since the subject came up, let me say that I wish no one would > hard-code their programs to use any system-defined directories to find > auxilliary files. When someone does this, I have to put the > auxilliary file there whether I like it or not. So, for example, > bison skeletons go in s:. Well, I want to put s: on my rad: disk, but Agreed, my S: is a zoo too. I suppose Fred puts his S: into RAD: in order to get extra speed when executing scripts. So why not enhance the resident command (I use ARP) in order to allow users to make script files resident?. In certain cases this would save a lot of time. It would be nice if this will be implemented roughly as follows: ARP's resident is "load-on-demand" so if a file specified in the resident list gets loaded, it should: -Lock the file and note the flags and filesize. -Read the first few bytes in order to be able to check if this is an executable ($3F3), a normal script, or an AREXX script. -LoadSeg in case of executable. -Load entire file when script. -Do not make resident if evidence contradictory. I've had some problems when using pipes in aliases. As far as I've been able to determine, it is impossible to use the "|" symbol directly when defining an alias. My solution to this has been to define an environment variable Pip="|", and use f.e. 'alias E List [] LFORMAT "%S%S" $Pip EdLaunch' instead. Still, a change to the ARP Alias or command-line interpreter, fixing this problem, would be preferable. -- -Albert (hp4nl!neabbs!ajbrouw) Optimize your options, both in quantity and quality.
pds@quintus.UUCP (Peter Schachte) (11/15/89)
In article <245612@neabbs.UUCP> ajbrouw@neabbs.UUCP (ALBERT-JAN BROUWER) writes: > I suppose Fred puts his S: into RAD: in order to get extra speed when executing >scripts. So why not enhance the resident command (I use ARP) in order to allow >users to make script files resident?. Actually, you can almost do this now yourself. You can use the PATH device (which came of c.s.a a while back) to allow you to assign S: to first RAM:S and then SYS:S. So when you try to execute a script, it first looks in RAM:S and then, if it can't find it, in SYS:S. Unfortunately, this won't automatically cache a script in ram the first time you use it, you'll have to copy it there yourself. Worse, though, is that any program that tries to write into S: will fail. And you can't do a dir of S:. Maybe what's needed here is a CACHE: device, that lets you specify files to cache, loads them into memory the first time you read them, and then reads them from memory thereafter. Of course, it would manage LRU dumping of the cache, and would handle out-of-memory conditions. It's amazing what you can do with devices (if you can only figure out how to write them)! -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds