Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bloom-beacon!athena.mit.edu!cthulhu
From: cthulhu@athena.mit.edu (Jim Reich)
Newsgroups: comp.sys.amiga
Subject: Re: User Friendly?
Message-ID: <3459@bloom-beacon.MIT.EDU>
Date: 4 Mar 88 18:58:10 GMT
References: <1150@pasteur.Berkeley.Edu> <43849@sun.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: cthulhu@athena.mit.edu (Jim Reich)
Lines: 20

In article <43849@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>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?
No, they shouldn't be forbidden.  The best way I know to handle this is the
way UNIX (or at least the cshell) does -- suspend interactive processes and
warn the user.  That way, they can be brought into the foreground with a
command such as 'fg' and can resume once they're interactive...

>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. 
Or suspend it.  Hmm, sounds like a yet another feasible, useful, neat
project which I don't have time for.  I wonder, how much modification would it
take to the CLI to allow ANOTHER CLI to take over such a process and make it 
interactive in another window (as in "OOPS.  Put diskcopy in the background.  
What can I do?  I know, I'll pop up another CLI, look up the ID of the evil 
diskcopy and then fg it in the other CLI."  Any takers for this project?
Perhaps the next version of Matt's shell?
						-- Jim