Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: User Friendly?
Message-ID: <43849@sun.uucp>
Date: 2 Mar 88 18:55:50 GMT
References: <1150@pasteur.Berkeley.Edu>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 26

In article <1150@pasteur.Berkeley.Edu> (Jonathan Dubman) writes:
>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...)

Yes and no, (on the deficiency that is). First off, there is a DOS call
IsInteractive() which is pretty analagous to the UNIX isatty() call. 
If that returned FALSE you probably want to abort the diskcopy *or*
have diskcopy open a new window where the I/O should go. 

On a side comment on the original problem : A) Deluxe Paint II has a menu
option to turn the workbench back 'on' (it reopens it). B) Neither Deluxe
Paint I or Deluxe Paint II can close the workbench if there is an open 
CLI on it so 'running' DPaint from a CLI will keep the WB there and you
can pop back to it to do what ever you chose (and have memory for). The
example of Deluxe Paint is a bad one since here is a program that is 
*desperate* for chip memory. Closing the workbench can help there, especially
on small memory machines, and since the way to get the workbench back
is clearly documented I don't understand why all the frustration.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.