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...