mp1u+@andrew.cmu.edu (Michael Portuesi) (07/02/88)
> *Excerpts from ext.nn.comp.sys.amiga: 27-Jun-88 Re: POPcli bug? (was Re:* > *Co.. Kim DeVaughn@amdahl.uts. (1635)* [about Dmouse CLI's not inheriting the correct PATH] > Or maybe try compiling DMouse with the alternate startup code that Carolyn > (I think) posted. Or just bite the bullet and put the "path" command in > your "from" file. I'd suggest adding a "cd" command to the dir you want to > be in, up at the top of the "from" file also (see previous followup for why). That is a totally unacceptable solution. 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? One very tiny problem with Dmouse 1.07: The pointer is automatically blanked when the screen is blanked irregardless of whether or not mouse blanking is enabled. However, when mouse blanking is disabled, the mouse pointer does not reactivate along with the display on a keypress. It does reactivate with the display on a mouse movement. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"
dillon@CORY.BERKELEY.EDU (Matt Dillon) (07/05/88)
>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? >One very tiny problem with Dmouse 1.07: > >The pointer is automatically blanked when the screen is blanked irregardless of >whether or not mouse blanking is enabled. However, when mouse blanking is >disabled, the mouse pointer does not reactivate along with the display on a >keypress. It does reactivate with the display on a mouse movement. Ahhh ... right, because you have mouse blanking disabled it *should* turn back on when the screen is unblanked. By the way, as per somebody's suggestion I am now using UpFrontLayer() etc... instead of the intuition WindowToFront() etc... calls, which appears to fix all instances of lockup with workbench icons. It will be in 1.08 (but so far that's the only thing I've added since 1.07, so I'm not releasing 1.08 yet). -Matt
eachus@mitre-bedford.ARPA (Robert Eachus) (07/09/88)
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...