jmg@dolphy.UUCP (Jeffrey Greenberg) (01/21/87)
(Caveat: Much of this is from memory! ("Embarassment is the highest
state of conciousness" - Anon.))
shl is a different approach to job control then berkeley's older
system. It functions primarily through the terminal driver, then through
kernel signals... that is, there is no SIGSTOP, etc. It is a far
cleaner an implementation. The term & col stuff is not kept
in the kernel (it doesn't belong there).
In BSD, processes must be coded to properly handle job control. In sys5,
whoever manipulates the terminal driver, is in control.
However, as is ususal, BSD is far sexier and idiosyncratic. Job control
for the user is far more usuable. This is because it is built into csh, and
is all that recommends it. Sys5's sh & korn-sh (at least ours)
doesn't know about job control so one is left to use the poor 'shl' program.
The 'shl' program is a sketch of a program. I believe that ATT has
a decent interface somewhere or a shell modified for job control -
there's money to be made with a decent Sys5 job control interface.
Shl is a program that only does the following: create a seperate shell on
same terminal; switch from one to the other; cause them to suspend on
input or output; resume them; and change what - if anything - they'll wait for.
All the functionality one wants. However, shl is not a real shell, lacking
all the language constructs, aliases, etc.
In summary: I used to use BSD job control but on system 5, with shl, I
do not. It's too clumsy.
--
Jeffrey Greenberg - {cmcl2,allegra}!phri!dolphy!jmg
NSA terrorist CIA cryptography DES drugs NRO cipher IRS secret RSA decode
coke libyan crack pot LSD russian nuclear missile atom assassinate guy%gorodish@Sun.COM (Guy Harris) (01/22/87)
> In BSD, processes must be coded to properly handle job control. In job control, programs that *want to know* about job control, or that have sections where they don't want to be stoppable, must be changed to know about job control. Most UNIX utilities don't know about it. In shell layers, programs that want to know that the terminal has been taken away from them have no way of finding this out. Thus, if they have to reset some mode in the terminal (not in the terminal driver, but in the terminal itself - e.g., turning off Tektronix mode on a VT100 with a Tektronix emulation board) can't be told when to do so. > Sys5's sh & korn-sh (at least ours) doesn't know about job control That's because vanilla System V doesn't *have* job control. "ksh" will support job control on systems which have it. In fact, I've seen code in "ksh" that looks like it tries to use the shell layers kernel support to implement something sort of like job control, if you have shell layers kernel support but not job control.
jpn@teddy.UUCP (01/24/87)
In article <114@dolphy.UUCP> jmg@dolphy.UUCP (Jeffrey Greenberg) writes: >In BSD, processes must be coded to properly handle job control. In sys5, >whoever manipulates the terminal driver, is in control. Wait just a second!!! "simple" BSD tasks do NOT need to be recoded to be manipulated with job control (i.e they can be stopped and started just fine, thank you), but tasks have the CAPABILITY to catch signals which indicate a job state change. In other words, if you don't recode any BSD tasks (except the shell, perhaps), it works just like "shl". On the other hand, editors can fix the tty mode and redraw the screen if they want to. Shl has two major flaws, in my opinion: 1. You must set it up in advance (i.e the normal shell can't take advantage of it). 2. Tasks have no notification of state changes. Perhaps if the Shl layer also did screen maintainance (restoration), this would be OK, but raw shl is happy to let the screen get botched. As far as I can tell, it is not POSSIBLE to write a "shl" that fixes the screen. Well, maybe with special tty drivers and such. Both shl and "job control" are unnecessary if you have a true windowing system. Both are HACKS to provide capabilities close to window systems using dumb terminals.
dcm@sfsup.UUCP (01/24/87)
In article <114@dolphy.UUCP> jmg@dolphy.UUCP writes: >(Caveat: Much of this is from memory! ("Embarassment is the highest >state of conciousness" - Anon.)) > > [...] >I believe that ATT has >a decent interface somewhere or a shell modified for job control - >there's money to be made with a decent Sys5 job control interface. >Shl is a program that only does the following: create a seperate shell on >same terminal; switch from one to the other; cause them to suspend on >input or output; resume them; and change what - if anything - they'll wait for. >All the functionality one wants. However, shl is not a real shell, lacking >all the language constructs, aliases, etc. > >In summary: I used to use BSD job control but on system 5, with shl, I >do not. It's too clumsy. DISCLAIMER: While I do work for AT&T, the opinions expressed herein do not represent those of AT&T, Bell Laboratories or any affiliate thereof. Well, there is a good explanation for shl... it's a kludge! Allow me to illucidate. Shl is actually a hacked down version of a much more elegant user interface. For those who haven't seen a 5620 Dot-Mapped Display it's an intelligent terminal with upto 1M of RAM, a 68000 or a Bell MAC 32000 processor, 800x1024 pixel (88x70) display, and a window manager in firmware With a dmd you can have 6 windows active with the host (beginning to sound familiar?) Well, after 6 concurrent windows, the shell on any other terminal seems very 1 dimensional. So, somewhere along the way, someone hacked the layer manager out of the window manager and it became shl. Shl was an afterthought. So, no, there is no great shell that works with shell layers and (sigh) nothing quite like BSD job controls. The dmd however is really a lot of fun. David C. Miller, consultant AT&T Information Systems 190 River Road Summit, NJ 07901 (201) 522-5149 {allegra,burl,cbosgd,clyde,ihnp4,ulysses}!sfsup!dcm
csg@pyramid.UUCP (01/25/87)
In article <3702@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >Both shl and "job control" are unnecessary if you have a true windowing >system. Both are HACKS to provide capabilities close to window systems >using dumb terminals. Not true at all. Whether I use my AT&T DMD or a Sun workstation, I won't give up BSD job control inside my windows! How much I depend on it became painfully obvious when using a pure System V workstation (which at the time didn't have shl either). The ability to stop and reorder jobs without killing them is much too useful to give up, particularly on systems with restricted resources. I do have less use for shl in the DMD windows (shl and SXT are just munged versions of layers and XT, after all), although I occasionally find it very useful for managing a large number of small tasks that produce little output. <csg>
roy@phri.UUCP (01/25/87)
In article <3702@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: > Both shl and "job control" are unnecessary if you have a true windowing > system. Both are HACKS to provide capabilities close to window systems > using dumb terminals. Weeeell, I don't know about that being 100% true. I've got a Sun on my desk with lots of lovely windows, and I still use regular 4.2 job control for several reasons. First, starting up a new window is expensive both in terms of memory and cpu time; on an otherwise quiet 3/50, it takes a few seconds to get a new shelltool window up. Even if I just open up one of my random iconic shells, it still takes a second or so. Hitting ^Z gets me a new % almost instantaneously, plus I don't have to take my fingers off the keyboard. Second, every window has its own history list; sometimes this is good, sometimes it's a pain. BTW, I find that printing a history list and doing "put then get" from it is usually much faster and easier than all that !foo:s/bar/baz stuff. Third, it's not that uncommon that I have something big running in a window off to the side someplace and want to stop it for a while so my quick troff job doesn't have to compete for CPU cycles with my monster compile job. The bottom line is that while much of what I used to use csh job control for I now do better with windows, both have their uses and I wouldn't want to be without either. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
wombat@ccvaxa.UUCP (01/29/87)
/* Written 5:21 pm Jan 23, 1987 by jpn@teddy.UUCP in ccvaxa:comp.unix.questions */ Both shl and "job control" are unnecessary if you have a true windowing system. Both are HACKS to provide capabilities close to window systems using dumb terminals. /* End of text from ccvaxa:comp.unix.questions */ Close, but not quite. I used to run a very CPU-intensive process overnights (specifically, running test suites on a software emulator for a different machine). Because other people used the same machine for their heavy computing during the day (more copies of the same emulator), and because they usually got to work before I did in the morning, I could get up early, dial up, send the process a SIGSTOP, and *not* get nasty mail about letting the thing run unwatched during the day. When I came in to the office, I just sent it a SIGCONT and poked around with what it had been working on. Try doing *that* with a window system. "What the hell do you pack anyway, when you're off to see a two-ton messenger from the stars buried at the end of the world's largest sewer?" K.W. Jeter, *Dr. Adder* Wombat ihnp4!uiucdcs!ccvaxa!wombat
lars@myab.UUCP (Lars Pensj|) (01/29/87)
In article <1055@sfsup.UUCP> dcm@sfsup.UUCP (David C. Miller, consultant) writes: >... So, no, there is no great shell that works with shell layers >and (sigh) nothing quite like BSD job controls. The dmd however is really >a lot of fun. > It is quite possible to make csh use the sxt devices. We have done such an implementation, and are now using csh in place of sh. Result: ++++ Possibilities to switch between 7 jobs and let them run in the background. - Csh doesn't modify tty name in wtmp. We "hacked" getlogin() to do it another way, and relinking all programs using it. - Csh have problems handling type ahead, because typed characters are associated to the sxt device attached to the current process. When the process exits, csh has to read them back from this device. - A process can not know whether it is blocked or not. +! Processes are not stopped, they are blocked (terminal i/o). * When any process (e.g. stty) changes the baudrate, the current sxt device gets another baud rate than all other jobs (very fun, but fixed nowadays). - The modifications are not public domain. We also implemented this in tcsh.
nz@hotlg.UUCP (02/02/87)
In article <3702@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: > In article <114@dolphy.UUCP> jmg@dolphy.UUCP (Jeffrey Greenberg) writes: > >In BSD, processes must be coded to properly handle job control. In sys5, > >whoever manipulates the terminal driver, is in control. > > Wait just a second!!! "simple" BSD tasks do NOT need to be recoded to > be manipulated with job control (i.e they can be stopped and started just > fine, thank you), but tasks have the CAPABILITY to catch signals which > indicate a job state change. True, but not the whole truth. A process has the option of catching the signal (SIGCONT) that re-starts it, and thus be notified of a change of state from BLOCKED to READY (remember your OS classes?). Since there are two stop signals (SIGTSTP and SIGSTOP) you get flexibility on READY|RUNNING to BLOCKED state change, SIGTSTP can be caught (and the state change defered or even defeated), SIGSTOP can not be caught or ignored and in most cases the R|R to BLOCKED state change is guaranteed to occur. > > Shl has two major flaws, in my opinion: > > 1. You must set it up in advance > > 2. Tasks have no notification of state changes. Both of these are flaws, but the main problem is the whole philosophy behind shl. It is simply NOT a general facility. While it may be nice for users some of the time, it is not good enough to let you manage multiple stacks of BLOCKED processes, and it is no help to the programmer. > > Both shl and "job control" are unnecessary if you have a true windowing > system. Both are HACKS to provide capabilities close to window systems > using dumb terminals. Wrong. For a user, a windowing system does just about everything he could want, but it still exhibits the same philosophy as shl: the only reason to control a process is so a user can run multiple processes. I think it is best to have BOTH job control (a general process-control facility) and window management (a general user-interface facility). Job control could be very helpful for the window manager designer/programmer. A programmer writing a package that uses multiple concurrent processes (none of which talk to a terminal, so much for the tty driver control approach) can make good use of the ability to asynchronously start and stop processes. Other advantages acrue, but you would have to have used a BSD system for a while to really get into them. -- ...nz (Neal Ziring @ ATT-BL Holmdel, x2354, 3H-437) "You can fit an infinite number of wires into this junction box, but we usually don't go that far in practice." London Electric Co. Worker, 1880s
simon@its63b.ed.ac.uk (ECSC68 S Brown CS) (02/05/87)
In article <164@myab.UUCP> lars@myab.UUCP (Lars Pensj|) writes: > >It is quite possible to make csh use the sxt devices. We have done >such an implementation, and are now using csh in place of sh. Strangely enough, I've done the same for sh (and of course am using it in place of csh :-) ). > >Result: > >++++ Possibilities to switch between 7 jobs and let them > run in the background. Seven because the shell itself is using channel 0 for input/output of commands - but in that case, there is a little problem with terminal groups; namely: The shell can't just keep its old "real" tty as its controlling terminal because this cannot be accessed (via read(2)) any more once an sxt cluster has been multiplexed onto it, so the shell will have to take over sxt channel 0 for its own purposes. The only way of getting a new terminal as your controller is to do the following: 1. Do a setpgrp(). 2. Open a new terminal. So, you would naturally think that the way to get an sxt chan 0 for your shell's controller would be to do this: 1. setpgrp(); 2. open("/dev/sxt??0",2); All well and fine - until you try to multiplex the rest of the cluster onto chan 0 (SXTIOCLINK ioctl) - for this to work, your controlling terminal must be a "real device" (not an sxt), so you can't put the setpgrp() there. And if you don't do that, then sxt??0 is not set up to be your controller. Ok, next attempt is probably 1. fd=open("/dev/sxt??0",2); 2. ioctl(fd,SXTIOCLINK,...); 3. setpgrp(); 4. open("/dev/sxt??0",2); ie, re-open the chan-0 device. But this falls over because of the "ownership" problem with sxt's. [Brief summary: A standard non-priviliged user will need to be able to open these sxt devices in read/write mode. But once they have done so, nobody else had better be able to do so! (for obvious security reasons). Also, programs such as shl are pretty untidy about the mess they leave behind them - shl chown()'s the sxt's to the userid of whoever is using them, but doesn't chown back to some standard user (root?) afterwards. So, if 16 people logged in and ran shl and logged out again, then all the sxt devices will be owned by them and only them - nobody else ('cept root) has a hope of ever being able to access them again. (Subsiduary remark: My solution to this (pretty crappy, I know), is to have a setuid service-program which "allocates" sxt's by chowning them to the real-uid of the caller. The job-control shell will then access an sxt device cluster by doing a) execute this "sxt-allocator". b) go through all the sxt's, trying to open each cluster's channel-0. If the open succeeds, then you've got one. It it fails with errno==EBUSY then keep on trying. If it fails with errno anything else, then give up and that particular instance of the shell can't have any job-control. c) multiplex the subchannels. d) set chan-0 to exclusive-use (TIOCEXCL ioctl) to stop anyone else from stealing it from under you. e) ...... Another advantage of this is that the setuid allocator can then modify utmp (you can't, 'cos you aren't root). If the shell calls the allocator again (when its finished being a shell), then utmp can be changed back again - its all pretty transparent. ) ] Or perhaps its not, actually. I'll have to think about this again :-) Anyway to get back to the original argument... you could fix this by making channel-1 the controlling terminal - but then you can only have 6 remaining subchannels, which isn't too many.. > >- Csh doesn't modify tty name in wtmp. We "hacked" getlogin() to > do it another way, and relinking all programs using it. You'd also have to "hack" all the functions in the getut(3) family. > >- Csh have problems handling type ahead, because typed characters > are associated to the sxt device attached to the current > process. When the process exits, csh has to read them back from > this device. That's ptetty straightforward - it means that anything typed while a process is getting 'round to dying off can be picked up by the shell and read as part of the next command - but you can't type further input and expect it to get picked up by the next command, 'cos it won't be: Example: $ ex filename # edit (or whatever) something) :q # quit mail fred # while its dying, start typing next command hello # ... and type some data as input? hi fred, this is mail..... ^D $ # shell-prompt, then it executes "mail" Subject: # ... huh? why is it waiting? I thought # ... I'd given it some input, it seems # ... to have forgotten that! ^D $ hello: not found # oh look! it stored up what I typed in $ hi: not found # the _shell_'s input buffer! Of course, if SysV provided a TIOCSTI ioctl call like BSD does, then this could be fixed by the shell's sticking the extra characters into the input queue of whatever sxt device is running next :-) > >- A process can not know whether it is blocked or not. Well...., if the sxt controller channel (chan 0) were left open, then processes could do a SXTIOCSTAT ioctl on it and look for themselves. But this would be gross. :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Simon Brown Department of Computer Science, University of Edinburgh, Scotland, UK. UUCP: ...!decvax!seismo!mcvax!ukc!{cstvax,its63b}!simon JANET: simon@uk.ac.ed.{cstvax,its63b}
simon@its63b.UUCP (02/22/87)
In article <1055@sfsup.UUCP> dcm@sfsup.UUCP (David C. Miller, consultant) writes: >... So, no, there is no great shell that works with shell layers >and (sigh) nothing quite like BSD job controls. The dmd however is really >a lot of fun. > I have posted a set of diffs for the sysV sh sources to implement job-control using sxt-devices, to comp.sources.unix (or mod.sources, or whatever it's called where you live :-) ). Unfortunately, this probably means it'll take a while to get out (what with being moderated, and all), but I can't post to net.sources (or unmoderated comp.sources.unix or whatever its called) from here, so that's just tough. Still, that's life for you ... The diffs will convert your shell into one with job-control which vaguely resembles BSD csh job-control, namely: fg [%job] brings a job back to the foreground bg [%job] resume a stopped job in the background jobs print list of jobs kill [-n] %job kill a job stop [%job] stop a background job %job same as "fg %job" %job & same as "bg %job" ^Z stop the current job There are certain differences from BSD job-control (mostly forced by the way sxt devices work - and mostly improvements too!). -- ----------------------------- Simon Brown @@@\ Department of Computer Science /-/@ \ University of Edinburgh, Scotland, UK. / /@ \@@ / /@ \-\ UUCP: seismo!mcvax!ukc!{its63b,cstvax}!simon / /@/-/ \ \ JANET: simon@uk.ac.ed.{its63b,cstvax} / /@/ / /-/ \ \ ARPA: simon@{its63b,cstvax}.ed.ac.uk /-/@/-/ /-/ \ \ ------------------------------ ~~~~~~~~~~~~~~~~~~~~ "Life's like that, you know"