Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!ncar!gatech!linus!mbunix!eachus From: eachus@mitre-bedford.ARPA (Robert Eachus) Newsgroups: comp.sys.amiga Subject: Re: Dmouse and PATH (was Re: POPcli bug? (was Re: ConMan Question)) Summary: I thought everyone knew how to fix this... Keywords: NewCLI Run Message-ID: <35804@linus.UUCP> Date: 8 Jul 88 18:22:06 GMT References: <8807050651.AA20133@cory.Berkeley.EDU> Sender: news@linus.UUCP Reply-To: eachus@mbunix (Eachus) Organization: The MITRE Corporation, Bedford, Mass. Lines: 72 In article <8807050651.AA20133@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>I have only one disk drive, and REZ a batch of commands so that I >>don't have to keep my startup disk around all the time. One of >>those commands is "newcli". If I am forced to use a "from" file to >>get the PATH set correctly, I will have to swap disks every time I >>want a new CLI. >> >>Perhaps Matt could possibly fix this problem in 1.08? > > Problem: How? Dmouse's process does not have a CLI so how does > Execute() know where to get the path from? > > In your case, you could simply put the script in RAM: or something, > no? .... > > -Matt The trick is that Execute calls C:Run. To get things to work without disk references you must do something very like this on start-up (In what follows order is very important, I've included comments in braces, and there are many things that can be done to speed things up which would only confuse the issue here): MakeDir RAM:C {or some such directory} Copy C:Rez RAM:C RAM:C/Rez {A long list of things that you use regularly possibly including NewCLI and EndCLI, you may even want to load some of them...} CD RAM: Copy C:Run RAM:C {This is the first part of the magic formula.} Copy C:Path RAM:C {This isn't strictly necessary (if what follows is done in the right order, and you Rez Path, but it seems like cheap insurance.} MakeDir RAM:S Copy S:NewCLI-startup RAM:S {If we're going to all this trouble, this file should also be memory resident. Be sure to put the path command first.} Path RAM:C {whatever else you want here} SYS:C Assign C: RAM:C {This is the magic squeaker, but be sure to put it after the above path statement...} AddBuffers ... DMouse ... "NewCLI FROM RAM:S/NewCLI-startup" ConMan ... ... EndCLI {No reason to keep a CLI around that doesn't use ConMan...} Now the calls to C:Run go to RAM:C, and assuming that you don't add additional paths in the path command in RAM:S/NewCLI-startup (i.e. there already exist locks for everything), and you haven't done a CD to someplace on a disk in there, you should have a new window, very quickly and without any disk lights flashing. Probably on the next screen refresh, although I don't know how to measure that :-). Anyone who thinks that all this is a kludge should check out typical .cshrc and .login files on Unix. My .login and .cshrc files on Unix are a lot longer (and accomplish a lot less) than the corresponding files under AmigaDOS. This is not a complaint. On Multics my start-up was longer and did more, on Stratus the same. This is a feature of good operating systems, and my comment about my Unix .login and .cshrc being much longer is due to the Unix standard environment being further from MY environment than on the Amiga, where I rename commands by renaming the files. (I hope someone is going to put links in the Amiga FFS...) Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...