pete@topaz.berkeley.edu.UUCP (06/08/87)
+++ I apologize if this posting has showed up at your place before, +++ but I sent it out a week or so ago, and as far as I can tell it +++ took off out of the Solar System... (If anyone DID get a duplicate +++ it might help if they sent me mail -- maybe I'd get a clue to what's +++ happening. Thanks.) -- Pete -- There was a discussion on the net a little while back on putting the temporary directory ':T' used by EXECUTE (and ED) in RAM:. I thought for a while that other people had done what I had -- modified EXECUTE so that it always worked in RAM:T instead of a T directory at the root level of the current device --, but I gather not, so for general information (and as a nudge to C-A) I'll post a brief description of my fix. For those tuning in late, the problem is that EXECUTE often has to write a temporary command file, with the parameters you supplied in the command line substituted into it; this is then passed as a set of commands to the CLI for execution. This file is written into ':T' at the top level of the device you happen to have been in when you called EXECUTE. There are two problems with this: first, it's annoyingly slow, by the time the original command file gets read, the new one gets written out, and then gets read back in again; second, I often want to call a command file from a write protected disk (or maybe a totally full one). Ny frustration with this situation eventually reached a level that forced me to do something about it. There are two things needed to do. You have to modify EXECUTE so that it uses DEVICE "T:", rather than DIRECTORY ":T". (I of course always rename EXECUTE to X -- you probably have your own favorite.) Then you must insert the commands "MAKEDIR RAM:T" and "ASSIGN T: RAM:T" into your startup-sequence, so that there is in fact such a device available. To fix the program file, I used "filezap". The one I have handy is from Fish Disk #14 -- I seem to remember a later version, but this one works fine. Using filezap (which should be fairly self explanatory) go to block 7, where you will see the string ":T/Command-T-01". All you have to do is edit this suitably, but you have to be a little careful, because this is one of those BSTRs, which is preceded by a character count, and is presumably also modified when used to reflect the process number. As long as you keep it the same length though you won't do any harm; I changed the first three characters only, to "T:_Command-T-01". Don't forget to use filezap's "Update Block" command after doing this, or you won't have done anything to the file at all. So now things happen nice and fast when I execute a command script. I also keep in RAM: all the scripts I use a lot, so using them is just like invoking any other command. (Okay, I admit that the command interface I wrote -- Sili(Con:) -- helps a lot there too, as it invokes EXECUTE automatically if the command is a script, and can find scripts elsewhere than in S:, but without that you can at least assign S: in RAM:.) So how about it, C-A? Is there any chance of you distributing an official version of EXECUTE that works that way? Because of copyright restrictions I can obviously only pass it around as a patch, but it's a shame that everyone's going to have to do it for themselves. -- Pete Goodeve --