Process control in Sys. 5

Leo de Wit leo at philmds.UUCP
Sun Aug 28 08:08:03 AEST 1988


Ok, here is what all you helpful people on the net sent me; thanks to all
that responded. System V seems indeed to have some kind of job control,
notably by shl(1). Enfin, you can see for yourself.

--------------------------- here it starts -----------------------------------
From: prlb2!uunet!dalsqnt!pigs!haugj (Joe Bob Willie)
    
    most of what you described is available in one form or another under
    system v.  but you must have sxt's and the shell layer manager for it
    to work.  the mechanism is different, but the results fairly the same.
    
From: mcvax!cvl!grs (Gregg Siegfried)
    
    Hi Leo.  I'll toss in my experience with job control on SV.2.. In a
    word, none. :-)  There is a utility called shell layers, or shl, that
    is supposed to allow this sort of thing, but it is fairly lame, in my
    opinion.  But, better than nothing.. It allows one to control 7 or 8
    shell processes, and run different things in each, block output, and
    switch between them relatively easily.  It has some downsides, though..
    if the process has any output that you want to see, after going off to
    do anything else, you should block the output.  The problem with this is
    that the process suspends until you unblock the output..But, I suggest
    your friend give shl a try. .. it uses the sxt pseudo devices.
    
    A preferable solution, the one that I utilize, is layers.  On an AT&T
    620 or 630 terminal, with adequate RAM and a mouse, one can open a number
    of shell windows, overlap them, reshape them, delete them, and run commands
    in them.  The 630 is definitely preferable.. it has a large screen, and
    a good built in mouse interface .. cutting things off one window and pasting
    them in another, etc.  Layers uses the xt pseudo devices.
    
    Neither of these is a direct substitute for job control, per se, but I
    find layers a very pleasant way to interface with the system.
    
    
From: mcvax!vsi!sullivan [Michael Sullivan]
    
    Have your friend read up on shl(1).  That's about it for SVR2.
    
From: mcvax!vsi!friedl [Steve Friedl]
    
    Hi Leo,
    
         Job control ala Berkeley is simply not available in System V
    Releases 2 and 3.   This requires support from the kernel that,
    I'm told, is easy but not there.  Depending on what your friend
    is doing, shell layers (the `shl' command) may be helpful.  It
    basically gives you several terminal session multiplexed onto a
    single terminal with ^Z to switch active layers.  This *is*
    different than Berkelix job control, and it may take a while to
    get the hang of why shell layers are nice.
    
         If shl looks helpful, send me a note and I'll give some
    more helpful hints.  Note that shl requires the sxt drivers,
    which some vendors (Plexus, for one) do not support.
    
         There are vague rumors that SVR4 will address job contro,
    but I really have no idea how.
    
This one is in Dutch, actually from someone working on the same floor;
I didn't take the effort to translate it.
From: hulsebos (Rob Hulsebos)
    
    Naar aanleiding van jouw vraag in 'comp.unix.questions' over 5.2 jobcontrol
    
    Er is in 5.2 een zeer beperkte vorm van job-control via 'shell-layers'. 
    Hiermee is het mogelijk een aantal (Bourne)-shells parallel te laten draaien,
    er is een 'foreground' shell en de rest draait in de background.
    
    Hier binnen I&E wordt ook nog een andere Unix gemaakt: het heet 'UniFive'
    en draait op VMEbus hardware. UniFive is een 5.2 kernel met BSD-networking
    en nog wat andere leuke dingen. De nieuwste release van UniFive, 3.1, kent
    ook de job-control van de C-Shell.
    
    Dat is waarschijnlijk datgene waar de gebruiker zo jaloers op is.
    
    Het zit ook in andere kommando's ingebouwd zoals 'telnet'. Maar het is dus
    geen standaard 5.2 feature.
    
--------------------------- here it ends -----------------------------------

        Leo.



More information about the Comp.unix.questions mailing list