mitchell@cadovax.UUCP (Mitchell Lerner) (01/14/87)
I need to be able to interactively stop jobs, start new ones, resume
jobs, that kind of thing in system 5. I'm used to Bsd and I'm gonna
be using system 5, and I'm wondering if shl layers will suffice for
my purposes.
Anybody used shl layers? How is it as a user interface? Can I do most
of the things that I can do under Berkeley's job control with shl layers?
Thanks.
--
Mitchell Lerner
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!mitchell
# cadovax!mitchell@ucla-locus.arpagwyn@brl-smoke.ARPA (Doug Gwyn ) (01/17/87)
In article <1324@cadovax.UUCP> mitchell@cadovax.UUCP (Mitchell Lerner) writes: >Anybody used shl layers? How is it as a user interface? Can I do most >of the things that I can do under Berkeley's job control with shl layers? "shl" can do most of the things you probably use 4BSD job control for, but it has some restrictions. One is that "shl" needs some "sxt" pseudo- devices; make sure there are enough for all the "shl" users on your system. The other main problem is that processes don't automatically repaint the screen when they get control of the terminal back.
monte@oblio.UUCP (Monte Pickard) (01/20/87)
In article <5528@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <1324@cadovax.UUCP> mitchell@cadovax.UUCP (Mitchell Lerner) writes: > >Anybody used shl layers? How is it as a user interface? Can I do most > >of the things that I can do under Berkeley's job control with shl layers? > > "shl" can do most of the things you probably use 4BSD job control for, > ... Good try Doug, but shl (shell layers) is a very poor excuse for job control under 4.2. Although I am basically a AT&T based UNIX devotee, this statement violates the 'fairness' rule. ( Unfortunately, most pro-4.x devotees violate the same rule in their arguments.) Monte Pickard - Counterpoint Computers
jc@piaget.UUCP (John Cornelius) (01/20/87)
In article <1324@cadovax.UUCP> mitchell@cadovax.UUCP (Mitchell Lerner) writes: >I need to be able to interactively stop jobs, start new ones, resume >jobs, that kind of thing in system 5. I'm used to Bsd and I'm gonna >be using system 5, and I'm wondering if shl layers will suffice for >my purposes. > >Anybody used shl layers? How is it as a user interface? Can I do most >of the things that I can do under Berkeley's job control with shl layers? I have and they seem to work fine. What layers actually does is to detach your terminal from the current process. If the process doesn't require input from the terminal it will continue to run. I suspect that if a detached process wants to output to the terminal as the standard error device it will do so without regard to whether the terminal is attached. This could cause some rather interesting screens. I do not believe that there is actually a SIGSUSP signal in System V so the process has to run until it wants to do I/O to the terminal. -- John Cornelius (...!sdcsvax!piaget!jc)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/20/87)
In article <380@oblio.UUCP> monte@oblio.UUCP (Monte Pickard) writes: -In article <5528@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: -> "shl" can do most of the things you probably use 4BSD job control for, -> ... -Good try Doug, but shl (shell layers) is a very poor excuse for job -control under 4.2. Is there some significant drawback other than the ones I had noted (where you elided them as "...")? How about some information?
simon2@its63b.ed.ac.uk (ECSC68 S Brown CS) (01/21/87)
In article <380@oblio.UUCP> monte@oblio.UUCP (Monte Pickard) writes: >In article <5528@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >> In article <1324@cadovax.UUCP> mitchell@cadovax.UUCP (Mitchell Lerner) writes: >> >Anybody used shl layers? How is it as a user interface? Can I do most >> >of the things that I can do under Berkeley's job control with shl layers? >> >> "shl" can do most of the things you probably use 4BSD job control for, Not true, if you really mean "shl" here, rather than "sxt devices". >> ... > >Good try Doug, but shl (shell layers) is a very poor excuse for job >control under 4.2. This is closer to the truth... - if you actually mean "shl", again. > >Monte Pickard - Counterpoint Computers And now for my own random thoughts on the matter: Actually, to compare the utility program "shl" with the concept of "job control" is not a very clever thing to do. More meaningful would be to compare the SysV implementation of "job layers" (sxt devices) in "shl" with the implementation of "job control" in "csh" or "ksh". I will agree that shl does not stand up to much comparison here. However... if the low-level stuff is compared, then the sysV job-control is not really so bad: it is possible to implement something that looks almost like Berkeley job-control by switching contexts between various sxt devices. Advantages of the sysV approach: o It is "job i/o control" rather than "job cpu control", which seems a "cleaner" way to do things. It is only necessary to suspend a process if it is trying to read or write to your terminal - you don't care whether its running or stopped (in the cpu sense) if its just number-crunching, or doing file i/o. One of the nice consequences of this is that suspending a process (by typing ^Z, or whatever your `swtch' characters is set to...) will not actually "stop" that process until it wants to do i/o. So you don't have to put it in the background if you want it to keep running. o There is no reason why programs should not be aware that they have been stopped/restarted, because the job-control shell could send them signals to tell them about this [perhaps using the user-definable signals SIGUSR1 and SIGUSR2]. I only send a signal when a job is restarted, 'cos this is the useful one (though it is quite possible to do both - if you aren't using the signals for something else, of course: it does tend to monopolize these signals for its own use [argument for there being a lot more user-definable signals!]). In fact, lots of BSD job-control code in programs can be used almost unchanged, if its within "#ifdef SIGCONT"'s, and SIGCONT is defined as SIGUSR[12] in <signal.h>. o Plus all the positive remarks about things that can also be done under BSD. Disadvantages: o There is a limit to how many jobs may be running simultaneously in a single "job group". This limit is in fact 8, which is far too small (and since the shell will almost certainly be using on of the 8, that leaves only 7). This is a direct consequence of implementing it with special devices in the way it's done. I suppose it could have been done with a smaller number of more-intelligent devices, which would increase the number to something more intelligent. o There is a limit to how many "job control groups" there may be active at any one time. This is 16, which is not really enough either. Actually, to get back to how its implemented again, the real "physical" limit imposed is the product of groups times groupsize (16 x 8, as its implemented). This is obviously cretinous. o "Shl" is a pathetic implementation of this. o The "terminal name" is different for each process (and different for the shell, in turn), which can confuse programs that use /etc/utmp for fetching terminal names. (getlogin() doesn't work too well, either). This is hacked in shl by modifying utmp whenever the "current layer" is changed. o Lots of the supporting stuff is very badly done. Like "setpgrp()", for example. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Simon Brown Department of Computer Science University of Edinburgh, Scotland, UK. ...!{seismo,decvax}!mcvax!ukc!cstvax[!its63b]!simon
aeusemrs@csun.UUCP (Mike Stump) (01/22/87)
In article <161@piaget.UUCP> jc@piaget.UUCP (John Cornelius, System Manager) writes: >I suspect that if a detached process wants to output to the >terminal as the standard error device it will do so without regard >to whether the terminal is attached. This could cause some rather >interesting screens. > >I do not believe that there is actually a SIGSUSP signal in >System V so the process has to run until it wants to do I/O to >the terminal. Just a slight fix here: Shl does work, but you can have only (did I say only?) seven shells running under it. For some odd reason our copy of Korn Shell does not want to seem to run under shl, (anybody want to comment?) but Bourne Shell, runs fine. Then again we are running SVR2 V2.0, 2.1 fixed some bugs in 2.0, so I would expect Korn to work with shl in 2.1. There is input blocking, the ability for shl to stop other shells from reading from the terminal, and there is optional output blocking via the `block' command in shl, and `stty loblk'. To get out of blocked mode, you can `unblock' in shl, or `stty -loblk' in the shell in which you want unblockedness. -- Mike Stump, Cal State Univ, Northridge Comp Sci Department uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs
guy%gorodish@Sun.COM (Guy Harris) (01/23/87)
> Advantages of the sysV approach: > o It is "job i/o control" rather than "job cpu control", which > seems a "cleaner" way to do things. Although, at times, it is useful to really stop a job. > o There is no reason why programs should not be aware that > they have been stopped/restarted, because the job-control > shell could send them signals to tell them about this > [perhaps using the user-definable signals SIGUSR1 and SIGUSR2]. No, not using SIGUSR1 or SIGUSR2, please. Those guys are called user-definable signals because they are to be used by each *application* as it sees fit, not by something considered part of the "system" (such as "shl"). > I only send a signal when a job is restarted, 'cos this is the > useful one Nope. You need a signal to tell the process it's having the screen taken away from it, so that it can clear the screen, turn off the Tektronix emulation mode in the VT100+Tek emulator terminal referred to in previous postings, etc.. > o The "terminal name" is different for each process (and different > for the shell, in turn), which can confuse programs that use > /etc/utmp for fetching terminal names. (getlogin() doesn't work > too well, either). This is hacked in shl by modifying utmp > whenever the "current layer" is changed. This is a depressingly common source of grief in UNIX. The Sun window system puts entries in "utmp" every time it opens up a terminal emulation window, just so that programs using that terminal emulator as their terminal don't get confused.
gwyn@brl-smoke.UUCP (01/24/87)
In article <213@its63b.ed.ac.uk> simon2@its63b.ed.ac.uk (ECSC68 S Brown CS) writes: >>In article <5528@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >>> "shl" can do most of the things you probably use 4BSD job control for, >Not true, if you really mean "shl" here, rather than "sxt devices". I had in mind that the principal use of job control might be for putting things "in the background" after-the-fact (as opposed to doing it in advance with &). That seems to be the main use of 4BSD job control by many of our users. "shl" appears to support this mode of interaction. Actually, I heard a rumor from a fairly reliable source that the original "shl" was developed mostly as a joke. It certainly isn't the same as 4BSD job control. On the other hand, the kludgery necessary in the kernel to support 4BSD-style job control is aesthetically revolting (and it has changed at least 5 times that I know of, from evidence collected while Ron's job-control SVR2 Bourne shell was evolving. Exploiting 4BSD job control (as in writing a job-control shell) is rather intricate and we keep finding things that don't quite work right due to subtleties that an ordinary programmer would be oblivious to. The best way to exploit job control, if your system supports it, is to just use somebody else's job-control shell that works and not try to use the facilities in your own code (other than the trivial matter of intercepting signals when the process state changes).
james@bigtex.UUCP (01/24/87)
IN article <5547@brl-smoke.ARPA>, gwyn@brl.arpa (Doug Gwyn) wrote: > Is there some significant drawback other than the ones I had > noted? Well, the obvious problem with System V layers is that there isn't any practical way to use them. The "shl" program is not a shell, and cannot be used as such, and AT&T's Bourne shell does not support layers. One has to run the shl program after logging in, and every time you use ^Z, you go back to this shl program, not to a shell. I have to wonder why AT&T bothered with layering if it wasn't worth the trouble of modifying a shell to use it. Perhaps one day the Korn shell will use it. The other obvious problem is the fact you noted: there is no way to communicate layers activity to programs such as vi and so forth. Screen oriented programs really do need to know when to repaint the screen, and as far as I know there is no way under System V for vi to find out when to redraw. If anyone knows of a practical way to use shl I'd be interested in hearing about it, but in the meantime I see no reason to link it into the kernel. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" (512)-328-0282
guy@gorodish.UUCP (01/26/87)
>I have to wonder why AT&T bothered with layering if it wasn't worth the >trouble of modifying a shell to use it. Perhaps one day the Korn shell >will use it. There is code in the Korn shell that looks like it was intended to do this; whether it works or not, I don't know.
hsc@mtuxo.UUCP (01/27/87)
The multi-screen user interface on the AT&T PC6300 PLUS UNIX SVR2 is built on shl layers. It does require a special tty driver to keep all the screen memories, but there is no reason an intelligent terminal couldn't do much the same thing. Most users find the interface very comfortable and flexible, especially with a color monitor to allow each environment to have its own color scheme. -- Harvey S. Cohen, AT&T Data Systems, Lincroft, NJ, mtuxo!hsc, (201)576-2485
simon@its63b.UUCP (01/28/87)
In article <12099@sun.uucp> guy@sun.UUCP (Guy Harris) writes: >>I have to wonder why AT&T bothered with layering if it wasn't worth the >>trouble of modifying a shell to use it. Perhaps one day the Korn shell >>will use it. > >There is code in the Korn shell that looks like it was intended to do >this; whether it works or not, I don't know. In fact, the extra code in ksh is not really this at all - it just implements a slightly modified version of shl to run under (as in "below") ksh, though I havn't bothered looking to see exactly how it differs from the standard shl. It certains *isn't* a case of the sxt layering stuff being understood directly by ksh. PS. If anyone does go about putting this stuff *inside* a shell, they'll have the nice experience of finding out just how dishonest the manuals are when it comes to describing things like sxt(7), setpgrp(2), termio(7), etc... :-) -- Simon Brown, Department of Computer Science, University of Edinburgh, Scotland, UK. ...!{seismo,decvax}!mcvax!ukc!cstvax[!its63b]!simon.
guy@gorodish.UUCP (01/29/87)
>It does require a special tty driver to keep all the screen memories, but >there is no reason an intelligent terminal couldn't do much the same thing. Yes, and once you've done that you basically end up with *real* layers, or something equivalent. However, there are a lot of terminals out there that can't do this. >Most users find the interface very comfortable and flexible... I'm sure they do, but this is completely irrelevant to the merits of shell layers in general. By putting in the special tty driver, you've essentially eliminated a major problem of shell layers, which is its inability to multiplex the display or to give programs hints to enable them to help multiplex the display. If you *don't* have some form of multi-windowing, though, the interface is drastically different and not quite so nice.