tim@ism780c.UUCP (Tim Smith) (04/22/86)
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