[comp.sys.amiga] POPcli bug?

kim@amdahl.uts.amdahl.com (Kim DeVaughn) (06/27/88)

In article <2002@ihlpm.ATT.COM>, jmdavis@ihlpm.ATT.COM (Davis) writes:
> While trying to setup a small ram disk with my most popular CLI
> commands I noticed that my PATH ADD command didn't work when I
> opened a new CLI with POPcli, but it was there (the new path)
> when I used CLI from workbench or newcli from cli. I haven't
> had much of a chance to play with this bug, but since we are
> on the subject of CLI and Conman bugs I thougt I would bring
> it up.
>
> Sure, I can get around it by having the POPcli command do a
> path add command, but what a kludge!!!
>
> Does anyone know if DMouse has this bug too?

Well, DMouse does exhibit this behavior ... as to whether it's a *bug* or
not, and whose it is, is an open question.  As I mentioned in a followup
I just posted (about a requester popping up for df0: when DMouse tries to
fire off a new CLI, if the drive is empty), I think this is really a
problem with the compiler's startup code.

I'd bet that the PopCli you are using is PopCli-III.  The older version,
PopCli-II *does* inherit the path, so you can always use it if this is
a real problem for you.

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

/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

tws@beach.cis.ufl.edu (Thomas Sarver) (07/02/88)

In article <2002@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes:
>In article <6558@jhunix.HCF.JHU.EDU>, ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) writes:
>
>While trying to setup a small ram disk with my most popular CLI
>commands I noticed that my PATH ADD command didn't work when I
>opened a new CLI with POPcli, but it was there (the new path)
>when I used CLI from workbench or newcli from cli. I haven't
>had much of a chance to play with this bug, but since we are
>on the subject of CLI and Conman bugs I thougt I would bring
>it up.
>
>Sure, I can get around it by having the POPcli command do a
>path add command, but what a kludge!!!
>
>> 

This is surely no bug.  It is a price we pay for having a newcli come from
nowhere.  When someone does a 1> NewCLI command, the newcli inherits most of
the attributes of its parent, including the path(s).

However, the PopCLI newCLI comes practically from nowhere (I personally don't
know) so it has nothing to inherit.  A good work-around (not kludge) is:

PopCLI 90 "Newcli CON:foox/fooy/foox/fooy FROM PopCLI-Startup"

This tells PopCLI what to execute when it is invoked (notwithstanding minor
syntax, check the docs) as well as setting the blank to 90 sec.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
But hey, its the best country in the world!
Thomas W. Sarver

"The complexity of a system is proportional to the factorial of its atoms.  One
can only hope to minimize the complexity of the micro-system in which one
finds oneself."
	-TWS

Addendum: "... or migrate to a less complex micro-system."