budget "job" control

[Tim Smith]

This posting is not for those with weak hearts.  There are some
real kludges discussed here.  THIS IS YOUR FINAL WARNING!!!
STOP READING NOW IF YOU WANT TO KEEP YOUR LUNCH!!!!

All the recent discussion on job control, shell layers, and
windows reminds me of a horrible kludge I once did as an
experiment.

I was using a kernel derived from something like UNIX/TS 1.0.  There
was no job control or shell layers.  I was no longer working for the
people who own the machine, so there was little chance to hack
something into the kernel.

I then noticed that all the programs I wanted to be able to control
had shell escapes ( qed, readnews, sh, cu ).  So I wrote two programs.

[ entering fuzzy memory mode -- details may be wrong ]

The first was called "save".  You used a shell escape to invoke it.
It took as arguments a program to run, and args for that prog.  For
example, from qed:

	!exec save readnews

Save would then wait for the child.  The other program was called "resume".
Resume took as an argument a pid.  It killed the process with that pid,
and then hung.  This is used to get back to a process suspended by save.

For example, if we decide while in readnews that we want to get back to
qed, we determine the pid of the save that qed is waiting for.  Then we
do the command

	!exec resume pid-of-save-that-qed-is-waiting-on

Resume kills the save, so that qed comes to life.  Readnews is hung up
waiting for the resume.  To get back to readnews, from qed we can say

	!resume pid-of-resume-that-readnews-is-waiting-on

The next step, which I never got around to doing, was to add symbolic names
to these programs.  Then one would be able to say

	!saveas FOO readnews            # I am FOO

and

	!resumefrom BAR FOO             # I am BAR, resume FOO

The amazing thing about this is that it actually worked fairly well!
It was a hassle finding out the pids, but I had a program called "me"
that is sort of like a fast ps -fu on the person running it, so that
wasn't much of a problem.

The main problem was that it is possible if you are careless to end up
with all your procs either waiting for resumes or being resumes!  I got
around this by writting a third program: "checkme".

Checkme just sat in the background, waiting for SIGQUIT.  Whenever it
got a SIGQUIT, it looked in /dev/kmem and determined if any procs were
waiting for TTY input on my TTY.  If none were, it would print

	?User screwed up again!

and give me a shell.

Except for checkme, this is portable to any UNIX, and requires no kernel
changes.  It should be possible to write a portable version of checkme
by having checkme run ps instead of looking at /dev/kmem.
-- 
Tim Smith       sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim