Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!mrspoc.transact.com!kayvan
From: kayvan@mrspoc.transact.com (Kayvan Sylvan)
Newsgroups: gnu.bash.bug
Subject: jobs.c and nojobs.c (Enhancement request for SYSV machines)
Message-ID: <m0gly3Q-000162C@mrspoc.transact.com>
Date: 11 Jan 90 06:13:00 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 44

I'm wondering what the status of jobs.c and nojobs.c is in future bash
versions. At present, jobs.c includes nojobs.c if JOB_CONTROL is not
defined.

Now, jobs.c implements a lot of nice features that seem to me to not
rely on JOB_CONTROL per se. Remembering child processes (and giving
the user access to the background processes) are things that bash can
do regardless of whether or not those processes can be restarted.

I would love to be able to do:

	bash$ notify=
	bash$ foobar &
	[1] [1234] foobar
	bash$ yowza &
	[2] [1237] yowza
	bash$ fg %1
	Job control not implemented in this bash
	bash$ jobs
	[1] foobar
	[2] yowza
	bash$ 
	[1] foobar done
	bash$ sleep 800 &
	[1] [1239] sleep 800
	bash$ jobs
	[1] sleep 800
	[2] yowza
	bash$ kill %2
	Terminated: yowza

The formatting of the output descriptions of the jobs is not quite
right but you get the idea...

Looking at the code in jobs.c, it seems that the intent is to do this.
Is this true? Is this something to wait for in 1.05?

I used to use a version of tcsh on a System V machine that did just
that. It made it so much nicer (not as nice as full job control, of
course) and the "jobs" command became second nature to me.

What do you all think?

			---Kayvan