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