Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!zooey.Berkeley.EDU!c162-fe
From: c162-fe@zooey.Berkeley.EDU (Jonathan Dubman)
Newsgroups: comp.sys.amiga
Subject: Re: User Friendly?
Message-ID: <1150@pasteur.Berkeley.Edu>
Date: 2 Mar 88 02:02:12 GMT
Sender: news@pasteur.Berkeley.Edu
Reply-To: c162-fe@zooey.Berkeley.EDU (Jonathan Dubman)
Organization: University of California, Berkeley
Lines: 35

>> I was in the CLI and did a "run diskcopy".  Diskcopy asked me to press
>> return, but because it was being run in the background, didn't accept any
>> input from my CLI.  It did, however, change my disk names to "DF0:BUSY" and
>> "DF1:BUSY", so that I couldn't access them.  With 1 meg of stuff loaded in
>> ram disk, I was forced to reboot the system.
>> 
>> 	*&(Jonathan Dubman)

>I can't really fault them for not including the ability to open a window in
>each of the various utilities accessable from the CLI, its extra space added
>for little purpose when Popcli will let you pop a new CLI any time you want.
>In your case, if you know beforehand that you were going to want another
>CLI, you should have typed 'newcli' to get another cli...

>David Albrecht

Yes - I should have typed newcli, but I didn't, and my computer became
useless.  DiskCopy locked both of my drives so nothing else could access them,
and it was waiting for a RETURN that it would never get because I can't send
any characters to a task running as a result of the "run" command.  I know
how to get around these things, but new users will not.  I suppose new users
do not start background tasks from the CLI, so it is not such a problem.

Moral of the story:  Don't run things in the background if they may
		     require input!

I think there is a basic deficiency here:  shouldn't tasks be forbidden from
requesting input if run as a background task without redirected input?
DiskCopy probably did a getchar() which is really an AmigaDOS read(), I think.
Now the output file handle is inherited from the CLI when you run a task
with the "run" command; what is the input file handle?  (I suppose this
depends on the startup code...)

Any ideas on any of this?

	*&(Jonathan Dubman)