Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!oliveb!amdahl!kim From: kim@amdahl.uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga Subject: Re: DMouse artifact (was: Re: ConMan Question) Keywords: conman needs workbench for first CLI Message-ID: <90r1Q93Bz31010uBBSc@amdahl.uts.amdahl.com> Date: 27 Jun 88 02:42:47 GMT References: <1357@tahoe.unr.edu> <6558@jhunix.HCF.JHU.EDU> <6585@jhunix.HCF.JHU.EDU> Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 52 In article <6585@jhunix.HCF.JHU.EDU>, ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) writes: > In article <8eXJ77752K1010c6iYg@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > >In article <6558@jhunix.HCF.JHU.EDU>, ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) writes: > :: I have experienced this problem too, but ONLY after I added > :: DMouse to my startup-sequence. I had assumed that DMouse is looking > :: for the Workbench disk, not ConMan. The problem does NOT occur if > :: I use PopCLI instead of DMouse. > : > :I would bet that you are using the "from" option on the newcli command > :with DMouse to startup something (shell, or whatever). > > Yes, I am using "from". HOWEVER, all of my system directories > are assigned to my hard drive, including "S:". My workbench disk > still gets a disk hit! Doesn't matter. I have *all* my system assigns to directories in vd0:, and had the same problem. Putting a "cd" (to what I consider my "home" dir in vd0:, as Matt suggested) cured the problem. As I understand it, what is happening is that when the program you're starting up in your "from" file tries to get a lock on it's initial current dir, it's getting a NULL. This means "the boot device" to some component of AmigaDOS, and since that currently means "df0:", it puts up a requester for that device. Note that the request can be satisfied by putting/having *any* formatted disk in df0:, including a blank one. Also, if you click on "cancel" a time or two, the requester will go away, and everything will proceed normally. I dunno whose "anomaly" this is, but I think it's really the fault of the compiler startup code (could be mistaken here), as it does not happen with PopCli-II, which was released using one of the older versions of Lattice. It does happen with DMouse (Manx v3.6), and something quite similar (if not exactly the same) happens with PopCli-III (newer version of Lattice). This was the reason I went back to the older PopCli-II, after all attempts to eliminate it failed with PopCli-III (though I didn't try the "cd" trick on it back then). A final note. PopCli-II initiated CLI's inhereted the path that existed when they were started. DMouse initiated CLI's do not, so you'll need to have a path command in your "from" file following the "cd" command to emulate what you got for free with PopCli. Seems like a step backwards to me (sigh). /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25