[comp.sys.amiga] Job Control not needed

mjw@f.gp.cs.cmu.edu (Michael Witbrock) (12/15/88)

ditto@cbmvax

>Of course, AmigaDos doesn't have job control, either, and people
>get along fine without it there.  (Job control is just a crutch

Actually, I'd rather not have to have two windows to pipe the results of 
my compile to more. It'd also be nice to be able to put things into the 
background after you start them.

I guess this is obvious, huh. 

sorry. michael




-- 
Michael.Witbrock@cs.cmu.edu mjw@cs.cmu.edu                          \
US Mail: Michael Witbrock/ Dept of Computer Science                  \
         Carnegie Mellon University/ Pittsburgh PA 15213/ USA        /\
Telephone : (412) 268 3621 [Office]  (412) 441 1724 [Home]          /  \
-- 

phil@titan.rice.edu (William LeFebvre) (12/29/88)

In article <3881@pt.cs.cmu.edu> mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes:
>ditto@cbmvax
>>Of course, AmigaDos doesn't have job control, either, and people
>>get along fine without it there....
>
>...It'd also be nice to be able to put things into the 
>background after you start them.

So start up another shell-in-a-window.  There should be a very easy way to
open another shell/CLI (via a hot key or menu item).  That way the old
window with the running program stays intact and input and output for the
old program don't get mixed up with new stuff.  This avoids alot of the
problems inherent in the BSD-style cshell job control paradigm.  "Now
which program did that output come from?  Darn, I forgot to set "tostop"!
Oh I need to put this one in the background so I can bring that other one
in the foreground to type my next line of input....let's see, that's "^Z",
"bg", "fg"---oops, wrong one---"^Z", "bg"---now which job was that?---
"jobs", "fg %4"; there we go.

Don't get me wrong:  I like job control.  But I like controlling multiple
processes via a mouse and windows better.

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil@Rice.edu>

david@ms.uky.edu (David Herron -- One of the vertebrae) (12/30/88)

In article <2408@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) writes:
>In article <3881@pt.cs.cmu.edu> mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes:
>>ditto@cbmvax
>>>Of course, AmigaDos doesn't have job control, either, and people
>>>get along fine without it there....
>>
>>...It'd also be nice to be able to put things into the 
>>background after you start them.
>
>So start up another shell-in-a-window.


Job control is oh so much more than just being able to use ^Z and fg
and bg to "control jobs".  It's being able to make a process stop
deat in it's tracks and being able to start it back up later.

Now maybe it'd be better to do this a la the /proc type stuff of
the later versions of research Unix.  (That is, open /proc/<proc-id>
and do an ioctl(fd,..STOP..,..) rather than signal(proc-id,SIGSTOP))

Yeh I prefer having multiple "jobs" by way of windows and mice and
that kind of thing.  I *ALSO* like to be able to stop and start processes
at will and sometimes use that capability by itself from time to time.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<--          Stop!  Wait!  I didn't mean to!

bader+@andrew.cmu.edu (Miles Bader) (12/31/88)

phil@titan.rice.edu (William LeFebvre) writes:
> >...It'd also be nice to be able to put things into the 
> >background after you start them.
>
> So start up another shell-in-a-window.  There should be a very easy way to
> open another shell/CLI (via a hot key or menu item).  That way the old
> window with the running program stays intact and input and output for the
> old program don't get mixed up with new stuff.

The time that I want job-control the most is when I *forget* to RUN a
program that opens its own window (and so does NO i/o to the original
cli window), but doesn't fork.  Even if I could start up a new cli
with a keystroke, I don't want to leave a cli window sitting around
doing nothing [and the orig cli has useful state, like conman command
history].  Often I realize my mistake after being in the program for a
while; it's usually a pain to exit and restart using RUN (and
sometimes, I run a program that CAN'T be stopped... Reboot time!).  It
would be MOST convenient to be able to put these things into the
background after-the-fact-- JOB CONTROL!

-Miles