tut@sun.uucp (Bill Tuthill) (02/25/86)
Let's not lose perspective by emphasizing differences between 4 BSD and System V. The two UNIX variants are at least 95% similar. It's not overly difficult to write software that will run on both (the more complicated the software, the harder it is, though). What's really good about UNIX was implemented by Thompson and Ritchie in the early days, and described in the famous CACM paper. The good stuff hasn't changed substantially since then. Just think of all the things that work on both 4.2 and SV: | > < cc, to name just a few. Adherents of 4 BSD think of themselves as rebels fighting evil Darth Vader and the Death Star, but in the real world, the distinction between good and evil isn't as clear as in the movies. Some people I know at a prestigious west-coast university just finished implementing alternatives to "cut" and "paste"; had they been familiar with System V, this wouldn't have been necessary. I can't help but form similar opinions about AT&T's networking efforts. I regularly use both 4 BSD and System V, and find the transition even less difficult than driving someone else's car. The main thing that bothers me about System V is the lack of word erase (^W) in the tty driver. It's like driving a car with no windshield washer. Others no doubt have different pet peeves. Bill Tuthill
scott@cstvax.UUCP (Scott Larnach) (02/27/86)
The one and only real thing which bugs me about system V is the total lack of job control. e.g. in the mail program and having to check something out .. fancy being faced with either writing your mail out (and later having to read it in again), or having to fork up another shell. With a big load up either of these options can be painful. The functionality of ^Z and fg is tremendous! Come on, AT&T, give me job control and I'll be a believer. -- Scott Larnach Janet: scott@uk.ac.ed.cstvax Edinburgh Unix Support Arpa: scott@cstvax.ed.ac.uk Tel: +44 31 667 1081 x2629 Uucp: scott@cstvax.uucp
rees@apollo.uucp (Jim Rees) (03/02/86)
Let's not lose perspective by emphasizing differences between 4 BSD
and System V. The two UNIX variants are at least 95% similar.
I don't buy it. One of our marketing guys actually counted up the number
of programs, library calls, and system calls that are identical in both
variants of unix, how many have the same name but do different things (setpgrp,
for example), and how many exist in only one variant. I don't remember
the exact percentage of those things that are the same in both variants,
but it was nowhere near 95%. The most commonly used command on many unix
machines is 'ls', and look at how different that is.
When was the last time you saw a C program over 500 lines long that would
compile and run under both variants with no changes or conditional code?
The differences are big enough to be a pain in the neck. I would sure like
to see them resolved.campbell@maynard.UUCP (Larry Campbell) (03/03/86)
> The one and only real thing which bugs me about system V is the > total lack of job control. e.g. in the mail program and having to check > something out .. fancy being faced with either writing your mail > out (and later having to read it in again), or having to fork up > another shell. With a big load up either of these options can be > painful. The functionality of ^Z and fg is tremendous! > > Come on, AT&T, give me job control and I'll be a believer. > -- > Scott Larnach Janet: scott@uk.ac.ed.cstvax > Edinburgh Unix Support Arpa: scott@cstvax.ed.ac.uk > Tel: +44 31 667 1081 x2629 Uucp: scott@cstvax.uucp Job control is pretty neat, if all you have is a dumb terminal. But an even better solution is virtual consoles, or windows. I have perhaps one of the most modest Unix configurations imaginable: a DEC Rainbow personal computer running VENIX (a V7 port). To this I have added virtual consoles, so rather than typing ctrl-Z and messing up my terminal screen and having my mail session scroll off the page while I check something out -- I just touch a function key and a different console appears. I can do whatever I like, then touch another key to zap me back to the (undisturbed) mail job. This happens at memory speeds -- i.e., instantaneously -- and required changes only to the console driver, not to the tty driver or kernel. Virtual consoles are a standard feature of VENIX when running on IBM gear, and also of XENIX I believe. I only had to roll my own because VenturCom doesn't provide it for Rainbows. I've never used a Sun, but I'm sure their windows are even nicer. The nice part about virtual consoles or windows is that they don't require special Berkeley-esque signals and terminal drivers and whatnot. Programs are completely unaware anything is going on; you don't have to hack your screen editor to repaint the screen when you reenter it. -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
guy@sun.uucp (Guy Harris) (03/03/86)
> The one and only real thing which bugs me about system V is the > total lack of job control. e.g. in the mail program and having to check > something out .. fancy being faced with either writing your mail > out (and later having to read it in again), or having to fork up > another shell. With a big load up either of these options can be > painful. The functionality of ^Z and fg is tremendous! > > Come on, AT&T, give me job control and I'll be a believer. To be fair, they do have "shell layers" which sort of gives you the same functionality (although, since it does not permit you to stop processes nor permit you to move jobs originally started in the background back to the foreground, it should not be called "job control"). It does not, however, understand that when a process gets moved to the background it might want to clean up whatever it's done to the terminal (painted the screen, put they keyboard in a funny mode, put it into graphics mode where putting "text" to the terminal really draws vectors, etc.), and might want to re-do same when it gets moved to the foreground again. As such, it isn't complete. (Please save flames about how windowing is the only right way to do things for those who can afford windowing systems; those of us with such systems can generally afford them, but not everybody can.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
chris@umcp-cs.UUCP (Chris Torek) (03/03/86)
In article <257@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >Job control is pretty neat, if all you have is a dumb terminal. >But an even better solution is virtual consoles, or windows. ... and goes on to describe how wonderful it is. It is nice indeed: I have a Sun here with windows. But then, it is also nice to have job control so that I can do similar things from home. (Or could, if I had a phone....) `Get better equipment' is, to many, an unacceptable answer, alas. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
ggs@ulysses.UUCP (Griff Smith) (03/03/86)
> > Job control is pretty neat, if all you have is a dumb terminal. But an > even better solution is virtual consoles, or windows. ... ... > > The nice part about virtual consoles or windows is that they don't > require special Berkeley-esque signals and terminal drivers and whatnot. > Programs are completely unaware anything is going on; you don't have > to hack your screen editor to repaint the screen when you reenter it. > -- > Larry Campbell The Boston Software Works, Inc. > ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street > UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109 Sigh. Just what we need to convince AT&T that their (our) imitation of job control is all we need, or that when windows come it will be completely unnecessary. I have a 5620, a nice 8.5 x 11 bit-mapped display with mouse and windows; I still use job control once in a while. For one thing, it's easier to move something to the background instead of drawing a new window. It's also nice to be able to stop things some times. If I have just gotten part way into a "make" and I remember that I missed something, I just stop the "make" while it fix the problem. I also like having the option of stopping a suspected run-away process instead of blowing it out of the water. Would you drive a car without brakes? -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
andrew@amdahl.UUCP (Andrew Sharpe) (03/03/86)
In article <67@cstvax.UUCP>, scott@cstvax.UUCP (Scott Larnach) writes: > > The one and only real thing which bugs me about system V is the > total lack of job control. > > Come on, AT&T, give me job control and I'll be a believer. Uhh, excuse me, but what about shell layers ( shl ) ? It does not give you job control, per se, but it does allow you to break out of a foreground process, to 'do something else'. -- Andrew Sharpe ...!{ihnp4,cbosgd,hplabs}!amdahl!andrew ***************************************** ___________ * The views expressed above are solely * ,/| _____ | * my cat's opinions, and do not reflect * | | |___ /| | * the views of the employees, nor the * | | | | | | * management, of Amdahl Corporation. * | | | | | | * * | | |__| | | * * | | / | | ,| * * | ~~~~~ |/ ***************************************** ~~~~~~~~~~~
gemini@homxb.UUCP (Rick Richardson) (03/04/86)
> > Job control is pretty neat, if all you have is a dumb terminal. But an > even better solution is virtual consoles, or windows. ... ... > > The nice part about virtual consoles or windows is that they don't > require special Berkeley-esque signals and terminal drivers and whatnot. > Programs are completely unaware anything is going on; you don't have > to hack your screen editor to repaint the screen when you reenter it. > -- > Larry Campbell The Boston Software Works, Inc. Let me point out the "poor man's window system" which comes with VENIX SVR2. They used a slight hack to the console driver on an IBM PC; it allows four FULL SCREEN login sessions on a CGA, plus one more if you also have the monochrome adapter attached. Potentially, an EGA adapter could have eight such login sessions. You switch sessions by pressing Alt-1 through Alt-4 for the CGA, and Alt-5 for the monochrome. Now, for the way I typically use UNIX as a programmer, I submit that this approach provides the most functionality for the least cost. 1) I can log in as ANY user, on ANY screen (except root can only login on screen 1). 2) I always have a full 25 x 80 to work with. 3) I can instantly switch screens. No delay while screen is repainted. 4) I don't have to pay for expensive large screens, either in dollars or in space. 5) I can still do graphics, but if I do, I lose the current displays on other screens. Not a huge loss, since I rarely use graphics. A typical usage for me might find: screen 1 root Just in case I need a kill, or to install something. screen 2 me Using editor or compiling screen 3 me "Hack" ready to play during long compiles screen 4 me Terminal emulator running to host. (yup, lots of times I download software to the PC/AT to compile it there during development - it compiles MUCH faster than the (unamed) super-mini compiles it) What am I missing? To my mind, nothing, really. I felt some amount of mouse envy a year ago. So I got one, wrote a mouse driver with pop up menus, and tried using it with the editor, spreadsheet, shell, hack, etc. Guess what - cobwebs all over the poor little thing now. I found it was only usefull with "PAINT" programs. If I could change anything, I'd go for a display with (more) lines of 132 columns. It seems to me that the memory (screen and program) necessary for a real window system is being poorly utilized for a great percentage of us. Even if the display hardware doesn't support multiple pages, the kernel could simulate this by keeping the pages in kernel memory and just block moving them out to the screen on a session change. My point is that while huge displays and window systems are fun, for most of us they are an unecessary waste of (money, CPU cycles, memory). One page on one screen wasn't enough, to be sure, but the "in vogue" solution of large displays and massive window systems is overkill. Rick Richardson, PC Research, Inc. (201) 922-1134 ..!ihnp4!houxm!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!!!
geoff@desint.UUCP (Geoff Kuenning) (03/04/86)
In article <1199@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes: > It's also nice to be able to stop things some times... > I also like having the > option of stopping a suspected run-away process instead of blowing it > out of the water. Would you drive a car without brakes? The reason Dennis Ritchie qualifies as a genius is because when we say "it sure would be nice to..." to him, he responds "yup, sure would" instead of "hey, yeah, I'll go hack it in." DISCLAIMER: I've never met DMR; I'm just making a point here. Read his paper on streams to hear in his own words how incredibly hard it is to come up with a simple unifying concept instead of a bunch of hacks like BSD. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
scott@cstvax.UUCP (Scott Larnach) (03/05/86)
campbell@maynard.UUCP <257@maynard.UUCP>: | Job control is pretty neat, if all you have is a dumb terminal. That's the problem. | I've never used a Sun, but I'm sure their windows are even nicer. They are nice. But we can't afford one (or other bit mapped terminal) for everybody. And although I've never used shell layers as in System V, I gather from those who do that they are oriented towards bit mapped terminals, and that on an ascii terminal it is easy to lose track of where you are. For such as myself, and I suspect a large proportion (at least) of us are in the same position, job control seems the most practical way of doing things. -- Scott Larnach Janet: scott@uk.ac.ed.cstvax Edinburgh Unix Support Arpa: scott@cstvax.ed.ac.uk Tel: +44 31 667 1081 x2629 Uucp: scott@cstvax.uucp
henry@utzoo.UUCP (Henry Spencer) (03/05/86)
> It's also nice to be able to stop things some times...
The ability to stop processes is quite independent of all the other goo
in job control, in concept at least. Adding something like this to SysV
would probably be a five-minute hack (given sources!). You need to have
another context around before you can actually do anything to stopped
processes, but a window system is just right for that.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrycampbell@maynard.UUCP (Larry Campbell) (03/06/86)
> It's also nice to be able to stop things some times. If I have just > gotten part way into a "make" and I remember that I missed something, I > just stop the "make" while it fix the problem. I also like having the > option of stopping a suspected run-away process instead of blowing it > out of the water. Would you drive a car without brakes? > -- > Griff Smith AT&T (Bell Laboratories), Murray Hill > Phone: (201) 582-7736 > Internet: ggs@ulysses.uucp > UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs ) It is nice to be able to pause things sometimes. I think this is a VENIX enhancement, but VENIX has suspend and resume commands (and the corresponding system calls) to pause and then resume a process. Yes, it is a bit more of a pain to go to another window, run ps, then issue a suspend command. I'd like to have job control. But given a choice between job control and windows, I'll take windows. -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
campbell@maynard.UUCP (Larry Campbell) (03/06/86)
> Let me point out the "poor man's window system" which comes with VENIX SVR2. > They used a slight hack to the console driver on an IBM PC; it allows four > FULL SCREEN login sessions on a CGA, plus one more if you also have the > monochrome adapter attached. Potentially, an EGA adapter could have > eight such login sessions. You switch sessions by pressing Alt-1 through > Alt-4 for the CGA, and Alt-5 for the monochrome. Pretty neat, but I wonder why they didn't do it for the monochrome display? I hate the CGA; I think its text display is completely unacceptable for day-in day-out use; and the EGA is expensive. I understand the technical difference between what it takes to do this for the CGA and what is required for the monochrome adapter (see below); doing it for the mono adapter just isn't that hard. > A typical usage for me might find: > screen 1 root Just in case I need a kill, or to > install something. > screen 2 me Using editor or compiling > screen 3 me "Hack" ready to play during long compiles > screen 4 me Terminal emulator running to host. Almost exactly the way I run (except instead of having a hack screen all ready to go at all times, I have a Jove screen). > It seems to me that the memory (screen and program) necessary for a real > window system is being poorly utilized for a great percentage of us. Even > if the display hardware doesn't support multiple pages, the kernel could > simulate this by keeping the pages in kernel memory and just block moving > them out to the screen on a session change. ... Exactly what my virtual console hack on the Rainbow does (and what could be done to support the IBM mono adapter). > ... My point is that while > huge displays and window systems are fun, for most of us they are > an unecessary waste of (money, CPU cycles, memory). One page on one > screen wasn't enough, to be sure, but the "in vogue" solution of large > displays and massive window systems is overkill. > > Rick Richardson, PC Research, Inc. (201) 922-1134 > ..!ihnp4!houxm!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!!! Yes, indeed. I sure would like a Sun, but I'd rather have four PCs with virtual consoles for four programmers than one Sun they have to share. -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
ggs@ulysses.UUCP (Griff Smith) (03/06/86)
> In article <1199@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes: > > > It's also nice to be able to stop things some times... > > I also like having the > > option of stopping a suspected run-away process instead of blowing it > > out of the water. Would you drive a car without brakes? > > The reason Dennis Ritchie qualifies as a genius is because when we say > "it sure would be nice to..." to him, he responds "yup, sure would" > instead of "hey, yeah, I'll go hack it in." > > DISCLAIMER: I've never met DMR; I'm just making a point here. Read his > paper on streams to hear in his own words how incredibly hard it is to > come up with a simple unifying concept instead of a bunch of hacks like BSD. > -- > > Geoff Kuenning > {hplabs,ihnp4}!trwrb!desint!geoff One comment in my defense: job control works in Eighth edition UNIX (V8). I don't know whether this is an oversight by the system impurity hit squad or a conscious effort to perserve an occasionally useful feature. I still think a tool for stopping processes is valuable; it is not really necessary that it also be usable as a terminal context switcher, but one convenient implementation has that side effect. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
rich@rexago1.UUCP (K. Richard Magill) (03/06/86)
In article <2864@amdahl.UUCP> andrew@amdahl.UUCP (Andrew Sharpe) writes: >In article <67@cstvax.UUCP>, scott@cstvax.UUCP (Scott Larnach) writes: >> The one and only real thing which bugs me about system V is the >> total lack of job control. >Uhh, excuse me, but what about shell layers ( shl ) ? It does not >give you job control, per se, but it does allow you to break out >of a foreground process, to 'do something else'. Aside from the fact that sxt requires kernal support that not all SYSV machines have, *something else*, indeed. So long as you have ksh, whose sxt job control crashes machines, running under shl so that you can read a new .*rc file to give you the same? environment you left especially resetting terminal characteristics *AND* you don't really want to background anything *AND* you don't mind a maximum number of processes *AND* you don't mind several processes on your screen at a time (this is most fun when each sxt has different stty params), *T*H*E*N* shl is a fair surrogate for "real" job control. You still can't stop & restart a process. ALSO, shl cannot be started under shl nor can shl be used as a login shell. I put shl in my .profile & use ksh as shell for nearly everything that will take it immediately on a 3b2 and ksh alone on a 7300. Given a choice, I prefer ksh on 4.x. K. Richard Magill
ka@hropus.UUCP (Kenneth Almquist) (03/07/86)
> One comment in my defense: job control works in Eighth edition UNIX > (V8). I don't know whether this is an oversight by the system impurity > hit squad or a conscious effort to preserve an occasionally useful > feature. Hmm. Has V8 cleaned up job control? (For example, start up readnews, read a bunch of articles, stop readnews with ^Z, and drop the phone line. What happens to the readnews? (It should be restarted and sent a hangup signal so it can update your .newsrc file.)) At any rate, I agree with your basic point. If after being given 7 years to think about the problem the best response to Berkeley job control that USDL can come up with is shl, it seems like they had better just install the Berkeley job control code. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
jdb@mordor.UUCP (03/07/86)
If you can't afford a Sun, but you can afford a Macintosh, and you're running BSD UNIX, then you may want to consider my window package for the Mac w/BSD called UW. (Other people are making efforts to port it to the Amiga and Atari ST, but I don't believe those are available yet.) UW is available via anonymous FTP from S1-C.ARPA (the filenames are "uwdist3.1", "uwdist3.2", "uwdist3.3", "uwdist3.4"). It was posted to "net.sources.mac" several months ago, so if you archive the source newsgroups you can get it from there. If all else fails you can mail to me, and we'll work something out (I don't like to send UW across multiple-hop UUCP connections because of its size). To avoid the cost of sending UW across the oceans, two people have graciously agreed to redistribute UW for me. If you are in Europe you should contact Guido van Rossum "mcvax!guido". If you are Australia, please contact Robert Elz (kre@munnari.OZ). -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
gwyn@brl-smoke.UUCP (03/09/86)
In article <168@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <1199@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes: > >> It's also nice to be able to stop things some times... >> I also like having the >> option of stopping a suspected run-away process instead of blowing it >> out of the water. Would you drive a car without brakes? > >The reason Dennis Ritchie qualifies as a genius is because when we say >"it sure would be nice to..." to him, he responds "yup, sure would" >instead of "hey, yeah, I'll go hack it in." I suspect there are other reasons, but this one is indicative. >DISCLAIMER: I've never met DMR; I'm just making a point here. Read his >paper on streams to hear in his own words how incredibly hard it is to >come up with a simple unifying concept instead of a bunch of hacks like BSD. A relevant observation here is that 8th Edition UNIX does have nice process control support, but it doesn't look at all like Berkeley's "job control" implementation. One wonders whether AT&T was smart enough to pick up /dev/proc etc. for inclusion in SVR3. Once one has the 8th Ed. process control hooks, one can implement terrific software such as the Process Inspector "pi" (also called the "transcendental" debugger, groan). The closest thing we (the public) have to "pi" at present is "dmdebug" (nee "joff"), which works only on DMD (Teletype 5620) downloaded processes. It's pretty spiffy! (Beats the heck out of "dbx" and BSD job control.)
gwyn@brl-smoke.UUCP (03/09/86)
In article <1200@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes: >One comment in my defense: job control works in Eighth edition UNIX >(V8). I don't know whether this is an oversight by the system impurity >hit squad or a conscious effort to perserve an occasionally useful >feature. I am curious about how this is accomplished; I don't see any SIGSTOP-generating character defined in TTYLD(4) (standard terminal handler line discipline). Perhaps there is an extra module slipped into place in your terminal stream; such a critter could easily catch e.g. ^Z and post a SIGSTOP. Streams make it easy to add features like this; you could even have a "Hazeltine tilde kludge" module..
ken@rochester.UUCP (Ipse dixit) (03/09/86)
In article <168@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >The reason Dennis Ritchie qualifies as a genius is because when we say >"it sure would be nice to..." to him, he responds "yup, sure would" >instead of "hey, yeah, I'll go hack it in." Reluctance to introduce new "features", sure, that is important. But I think also it's more hindsight than foresight. You have to be able to see how other people's hacks miss the mark to come up with a simplifying/unifying concept. But it still takes genius. There was a paper on Unix hacker types - innovator, fixer, consolidator, etc. in some past Usenix proceedings. Anyone have the reference? Ken -- UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken@rochester.arpa Snail: CS Dept., U. of Roch., NY 14627. Voice: Ken!
boyd@inset.UUCP (Boyd Roberts) (03/10/86)
>campbell@maynard.UUCP <257@maynard.UUCP>: >| Job control is pretty neat, if all you have is a dumb terminal. > Job control is pretty neat, if all you have is a maniac to implement it. The SysV shl is a much better implementation, because it's a "bolt-on". Not, a huge kernel/user level kludge/rewrite (4.N approach). The way to go is to buy a jerq (5620) and somehow run the V8 mux/jim etc. The stuff that comes with SysV is truly revolting, and almost unusable. Invest some time into fixing the SysVile layers mess. The V8 stuff is SOOOO sweet. Boyd Roberts +++ + ..!mcvax!ukc!inset!boyd + boyd@inset.co.uk + boyd@basser.oz + +++ "Isn't that kind of severe?"
ggs@ulysses.UUCP (Griff Smith) (03/10/86)
> In article <1200@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes: > >One comment in my defense: job control works in Eighth edition UNIX > >(V8). I don't know whether this is an oversight by the system impurity > >hit squad or a conscious effort to perserve an occasionally useful > >feature. > > I am curious about how this is accomplished; I don't see any > SIGSTOP-generating character defined in TTYLD(4) (standard > terminal handler line discipline). Perhaps there is an extra > module slipped into place in your terminal stream; such a > critter could easily catch e.g. ^Z and post a SIGSTOP. Streams > make it easy to add features like this; you could even have a > "Hazeltine tilde kludge" module.. Correct. There is a streams module that implements the BSD "new" line discipline. A V8 user gets access to the ^Z hook by running either csh or ksh, just as in 4.[123]BSD. Ksh just pops the standard line discipline and pushes the new one. A few of the "terminal I/O from/to background" features behave strangely; that doesn't seem to be much of a problem. To be fair, I doubt that many of the "true believers" who use V8 use job control. Most of the ones I see have 5620 bit-mapped terminals and use a stream-based window manager that may not have the right hooks for ^Z. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
davidsen@steinmetz.UUCP (Davidsen) (03/11/86)
In article <1307@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >> >> Job control is pretty neat, if all you have is a dumb terminal. But an >> even better solution is virtual consoles, or windows. ... ................ deletion ................ > >Let me point out the "poor man's window system" which comes with VENIX SVR2. >They used a slight hack to the console driver on an IBM PC; it allows four >FULL SCREEN login sessions on a CGA, plus one more if you also have the >monochrome adapter attached. Potentially, an EGA adapter could have >eight such login sessions. You switch sessions by pressing Alt-1 through >Alt-4 for the CGA, and Alt-5 for the monochrome. XENIX-286 for the AT (and I believe the XT version as well) offers ten virtual terminals using the same method. A limited number of them will be made active by default, and the user may either make special use of them or change configuration to start all of them for login. Since I don't need ten logins (four are nice, tho), I do some special things when I login to my "personal" id. For taking notes on phone calls and drop-in visitors is start a shell in window 9 which is already running in the correct directory and which has a modified prompt (to remind me where I am). In addition, I have a command which will start an additional shell in window ten if I want it. The advantage to me is that when I log out I don't have to log out in several places. I can still use the other five virtual terminals to login again if I'm doing something unusual. The commands which start the note taker are: (PS1="(note) $ ";cd $HOME/notes;sh -s) </dev/tty09 >/dev/tty09 2>&1 & -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "It seemed like a good idea at the time..."
isaac@mulga.OZ (Isaac Balbin) (03/14/86)
In article <865@inset.UUCP> boyd@inset.UUCP (Boyd Roberts) writes:
!
!
! Job control is pretty neat, if all you have is a maniac to implement it.
^^^^^^
Come on Mr Roberts. It has long been known that you dislike BSD
systems. I am not here to argue with you on that issue,
but I am here to take issue with you - and anyone else on the net -
on this ridiculous and insulting use of phrase you employ with wanton abandon.
It serves no more purpose than to convice many of us that your articles are
contemptuous and not for serious reading.
Well reasoned and intentioned articles do a lot more to
convince people than inane utterances.gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/15/86)
In article <865@inset.UUCP> boyd@inset.UUCP (Boyd Roberts) writes: > >The SysV shl is a much better implementation, because it's a "bolt-on". >Not, a huge kernel/user level kludge/rewrite (4.N approach). This isn't quite right. "shl" depends on the addition of an "sxt" pseudo-device driver to the UNIX System V kernel, since otherwise UNIX System V has no multiplexing or pseudoterminals. It also requires the addition of another special "switch" control character. It is true that the changes necessary to add shl/sxt are less extensive and less intrusive than those needed for 4BSD job control. >The way to go is to buy a jerq (5620) and somehow run the V8 mux/jim etc. >The stuff that comes with SysV is truly revolting, and almost unusable. >Invest some time into fixing the SysVile layers mess. The Blit/Jerq/DMD is indeed a nice alternative to job control, but of course it is not quite the same thing. I have both here and have found job control to still be of some (minimal) utility. I would much prefer full 8th Edition UNIX process control, though. Does anybody know for sure whether SVR3 includes this? Software for the Teletype 5620 (DMD) is available from AT&T. They provide it for VAX or various 3B machines, UNIX System V only; there is also a 4.2BSD port distributed by Teletype. At BRL we run the DMD software on a 4.3BSD kernel; it was built under our UNIX System V emulation, essentially unmodified except for layers, which was totally replaced by "mpx" (originally obtained from Teletype, then heavily modified at CWI in the Netherlands). The only thing missing is the hostagent feature, which can't be made to work reasonably with the Berkeley implementation of pseudo-terminals. I have also ported the DMD software to the Gould PowerNode (60x0/90x0) family. This software is available to sites that are properly licensed for it, as an added part of the BRL UNIX System V emulation for 4.2BSD.
lars@myab.UUCP (lars) (03/16/86)
>In article <67@cstvax.UUCP>, scott@cstvax.UUCP (Scott Larnach) writes: >> >> The one and only real thing which bugs me about system V is the >> total lack of job control. >> >> Come on, AT&T, give me job control and I'll be a believer. > >Uhh, excuse me, but what about shell layers ( shl ) ? It does not >give you job control, per se, but it does allow you to break out >of a foreground process, to 'do something else'. We have ported 'csh' to SVR2 using shell layers. Result: A program started with '&' runs in background. If it want to do tty input, it will hang until put in foreground. A background program can be put in foreground with the 'fg' command. A forground program can be stopped with the '^Z' key. Csh will then type 'blocked' and not 'stopped', because only tty io is blocked and the program continues. Typing 'bg' to a 'blocked' will enable output to tty for the blocked program. A maximum of 7 programs can be executed simultaneously. A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its screen. Csh reads 'type ahead' characters back from a blocked sxt and inserts them into the current input line. Otherwise, type ahead wouldn't have worked. Despite these limits, it is much better than 'shl' (which creates one new 'sh' for each "job"). -- ______________________________________________________ Lars Pensjo {decvax,philabs}!mcvax!enea!chalmers!myab!lars
friesen@psivax.UUCP (Stanley Friesen) (03/19/86)
In article <137@myab.UUCP> lars@myab.UUCP (lars) writes: > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its >screen. > When this is fixed I will admit that shell layers are a workable substitute for full job control! What good does it do to stop a job if I cannot restart it transparently? -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
henry@utzoo.UUCP (Henry Spencer) (03/23/86)
> >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its > >screen. > > When this is fixed I will admit that shell layers are a > workable substitute for full job control! What good does it do to stop > a job if I cannot restart it transparently? What good does it do to be able to stop and start jobs if every program has to know about it to redraw the screen? Also, what do you do about output from (say) grep, which prints output and terminates rather than sticking around to redraw the screen on request? The fact is, *both* job control and shell layers are brain-damaged. Both do the easy part of multiplexing -- centralized input administration -- without the hard part -- centralized output administration. Programs should not have to redraw the screen themselves, when they have done nothing to mess it up! Job control and shell layers are both cheap plastic imitations of real window systems. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
chris@umcp-cs.UUCP (Chris Torek) (03/26/86)
In article <6534@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >The fact is, *both* job control and shell layers are brain-damaged. Both >do the easy part of multiplexing -- centralized input administration -- >without the hard part -- centralized output administration. You should be careful with these ideas, Henry: someone is liable to use them. I know *you* would never actually suggest something like this, but now someone will hack up 4.XBSD to remember what each processes' screen looks like and redraw it when you `fg'! -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
keith@hp-pcd.UUCP (keith) (03/27/86)
> The fact is, *both* job control and shell layers are brain-damaged. Both > do the easy part of multiplexing -- centralized input administration -- > without the hard part -- centralized output administration. Programs should > not have to redraw the screen themselves, when they have done nothing to > mess it up! Job control and shell layers are both cheap plastic imitations > of real window systems. You've touched the root of the problem: the model for running multiple jobs. When I was demo-ing the HP Integral PC last year (its kernel is modified to support windowing), the first question some people would ask is "Does it have Berkeley job control?" My response was "You don't need it!" I had to show them the value of running several programs, each in it's own window. They had adopted a bad model for running multiple jobs. (Maybe this is the effect Dijkstra was talking about in his comment about Basic programmers being permanently brain damaged.) Keith M. Taylor Portable Computer Division Corvallis, Oregon hp-pcd!keith [ps. I've programmed in Basic; you may want to disregard this response!]
nz@wucs.UUCP (03/30/86)
In article <6534@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its > > >screen. A program can catch ^Z, by ``signal(SIGTSTP, stop_handler)''. Further, the program can also catch the continue -- which lets it redraw the screen or print a message or change its state or whatever. I have several programs which do both. > > When this is fixed I will admit that shell layers are a > > workable substitute for full job control! What good does it do to stop > > a job if I cannot restart it transparently? You can. > What good does it do to be able to stop and start jobs if every program > has to know about it to redraw the screen? Also, what do you do about > output from (say) grep, which prints output and terminates rather than > sticking around to redraw the screen on request? Since when does EVERY program have to redraw the screen? I stop and start compiles, makes, news-readers, mail, etc. and none of them do screen refreshes. > The fact is, *both* job control and shell layers are brain-damaged. Both > do the easy part of multiplexing -- centralized input administration -- > without the hard part -- centralized output administration. Programs should > not have to redraw the screen themselves, when they have done nothing to > mess it up! Job control and shell layers are both cheap plastic imitations > of real window systems. > -- > Henry Spencer @ U of Toronto Zoology Job control is a helluva lot more than a cheap imitation of a window system. It is a general method of allowing some user control of system features -- time sharing and resource sharing. Remember that ^Z is only a character hook to the rather general SIGTSTP signal! The ability to stop a process is a very nice features that is NOT unique to BSD Unix (TOPS-10 and TOPS-20 had it). Further, I think window systems are just fine, but they require VERY special hardware to give acceptable performance. Job control frees up system resouces by allowing processes to be swapped out. Window systems leave processes lying around, and clutter the system even more with a window managing process! The fact that a job can catch or not catch the SIGCONT as it pleases is a very useful FEATURE! I would be very annoyed if somebody put screen control into the kernel (!) and forces a screen update (expensive at 1200 baud) every time I jumped into and out of a process. Don't clutter this group with off-the-cuff opinions and snorts! Both job control and window systems have their place, and they can even work together. -- ...nz (Neal Ziring at WU ECL - we're here to provide superior computing.) {seismo,ihnp4,cbosgd}!wucs!nz OR nz@wucs.UUCP "You could get an infinite number of wires into this !*$$#!?! junction box, but we usually don't go that far in practice" -- Employee of London Electricity Board, 1959
dpk@mcvax.uucp (Doug Kingston) (03/31/86)
Shell layers is a way to get around not having true windowing. If you
have a real windowing system, then you don't need shell layers. As has
been mentioned by others, shell layers are deficient in several areas.
As for Berkeley job control, this is another matter. As a mechanism
for handling multiple jobs simultaneously, it is a poor second to
a true windowing system. I know. I use BLIT terminals and SUN-like
workstations every day. However, this does not mean I want to give
up the ability to STOP and RESTART jobs. By STOP, I mean really stop
the job and take it from the RUN queue. This is a very powerful
process control facility. This is an orthogonal capability to windowing
or layers. The two are complementary. One of my favorite uses for
BSD job control is taking core dumps of processes in infinite loops
or which have gone "catatonic". In order to get a consistent coredump
you must insure the process is NOT running. Job control allows you
to accomplish just that. It is then possible to safely collect the
processes context from /dev/*mem (using the "gcore" program in 4.2BSD).
You can then continue the process afterwards with no ill effects.
There are numerous other examples where this type of process control
is useful.
In summary, look at the broader uses of BSD job control before condemning
its usefulness. Its not just for allowing simultaneous processing. I would
urge other vendors to seriously consider adding this type of process
control facility. I believe that the BSD facilities and many more are
provided through /dev/proc on V8 Unix, although they may not be as efficient.
Cheers,
-Doug-
Doug Kingston, CWI ("mcvax"), Amsterdampdg@ihdev.UUCP (P. D. Guthrie) (04/01/86)
In article <1524@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes: >In article <6534@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its > > > >screen. >A program can catch ^Z, by ``signal(SIGTSTP, stop_handler)''. >Further, the program can also catch the continue -- which lets it redraw the >screen or print a message or change its state or whatever. I have several >programs which do both. On System V layers? I highly doubt it. That was the context of Henry's posting. This (as was explained before) is *not* possible with the current switch implementation as a signal is not generated. It might be an idea to have the tty driver generate SIGUSR1 when a switch character is entered - would break quite a bit of existing software though. > > > > When this is fixed I will admit that shell layers are a > > > workable substitute for full job control! What good does it do to stop > > > a job if I cannot restart it transparently? >You can. > > > What good does it do to be able to stop and start jobs if every program > > has to know about it to redraw the screen? Also, what do you do about > > output from (say) grep, which prints output and terminates rather than > > sticking around to redraw the screen on request? >Since when does EVERY program have to redraw the screen? I stop and start >compiles, makes, news-readers, mail, etc. and none of them do screen refreshes. > > > The fact is, *both* job control and shell layers are brain-damaged. Both > > do the easy part of multiplexing -- centralized input administration -- > > without the hard part -- centralized output administration. Programs should > > not have to redraw the screen themselves, when they have done nothing to > > mess it up! Job control and shell 2layers are both cheap plastic imitations > > of real window systems. > > -- > > Henry Spencer @ U of Toronto Zoology > >Job control is a helluva lot more than a cheap imitation of a window system. >It is a general method of allowing some user control of system features -- >time sharing and resource sharing. Remember that ^Z is only a character hook >to the rather general SIGTSTP signal! The ability to stop a process is a >very nice features that is NOT unique to BSD Unix (TOPS-10 and TOPS-20 had it). Yes, but in true windowing system this is unnecessary and I don't find myself missing it at all. > >Further, I think window systems are just fine, but they require VERY special >hardware to give acceptable performance. Not true. See the BLTJ article on the DMD's. >Job control frees up system resouces >by allowing processes to be swapped out. Window systems leave processes lying >around, and clutter the system even more with a window managing process! >The fact that a job can catch or not catch the SIGCONT as it pleases is a very >useful FEATURE! I would be very annoyed if somebody put screen control into >the kernel (!) and forces a screen update (expensive at 1200 baud) every time >I jumped into and out of a process. I do admit that there needs to be an extra signal which can be sent to a process when the size of the window is changed. This could be handled at a graphics library level though. > >Don't clutter this group with off-the-cuff opinions and snorts! Both job >control and window systems have their place, and they can even work together. Agreed. > >-- >...nz (Neal Ziring at WU ECL - we're here to provide superior computing.) > > {seismo,ihnp4,cbosgd}!wucs!nz OR nz@wucs.UUCP > > "You could get an infinite number of wires into this !*$$#!?! junction > box, but we usually don't go that far in practice" > -- Employee of London Electricity Board, 1959 -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson
friesen@psivax.UUCP (Stanley Friesen) (04/02/86)
In article <127@sering.mcvax.UUCP> dpk@sering.UUCP (Doug Kingston) writes: >Shell layers is a way to get around not having true windowing. If you >have a real windowing system, then you don't need shell layers. As has >been mentioned by others, shell layers are deficient in several areas. > >As for Berkeley job control, this is another matter. As a mechanism >for handling multiple jobs simultaneously, it is a poor second to >a true windowing system. I know. I use BLIT terminals and SUN-like >workstations every day. I agree, a windowing system is the best solution. The question is, can a practical windowing system be designed to work on a normal 24 X 80 ASCII terminal without graphics capability? Not everyone can afford fancy stuff like BLIT's and SUN's. We only have about three of them here at Pacesetter and they are reserved for CAD/CAE work! I am stuck with a normal terminal. In the absence of a windowing system for such terminals Berkeley job control is far better than what is available on Sys V. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
jpn@teddy.UUCP (04/03/86)
> > > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its > > > >screen. >A program can catch ^Z, by ``signal(SIGTSTP, stop_handler)''. >Further, the program can also catch the continue -- which lets it redraw the >screen or print a message or change its state or whatever. I have several >programs which do both. I sure wish people would read before flaming. The original article was talking about SHELL LAYERS "shl" which is a System V poor imitation of Berkeley job control. Under Shell Layers, a ^Z (or equivalent keystroke) passes the terminal input to a different program, but the program that was intercepted is not told, and is NOT EVEN STOPPED (output will continue).
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/06/86)
In article <580@ihdev.UUCP> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes: >I do admit that there needs to be an extra signal which can be sent to a >process when the size of the window is changed. This could be handled >at a graphics library level though. Any such implementation of SIGWINCH should ensure that the SIG_DFL action is to ignore the signal, not to terminate the process. I mention this because I see that AT&T hasn't yet changed the wording in the SVID to agree with the result of the P1003 discussion about this issue. SIG_DFL should NOT always mean "terminate".
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/06/86)
In article <1081@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >Not everyone can afford fancy stuff like BLIT's and SUN's. Teletype 5620 DMDs go for around $4000 last I looked. (Each host system also needs to license some software at a few thousand per system.) When you consider the "overhead" cost of supporting professional employees, which is typically about twice their salaries, there is no good excuse for companies not investing a modest amount in productivity improvement tools.
friesen@psivax.UUCP (Stanley Friesen) (04/07/86)
In article <1524@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes: >In article <6534@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its > > > >screen. > >A program can catch ^Z, by ``signal(SIGTSTP, stop_handler)''. >Further, the program can also catch the continue -- which lets it redraw the >screen or print a message or change its state or whatever. I have several >programs which do both. > This is only true on BSD systems! On SysV ^Z does NOT SEND A SIGNAL, so there is *nothing* to catch. This is what Henry was complaining about. (At least this is true of all SysV systyems I have ever heard tell of) > >Job control is a helluva lot more than a cheap imitation of a window system. >It is a general method of allowing some user control of system features -- >time sharing and resource sharing. Remember that ^Z is only a character hook >to the rather general SIGTSTP signal! The ability to stop a process is a >very nice features that is NOT unique to BSD Unix (TOPS-10 and TOPS-20 had it). However it is not found in SysV UNIX. On ATT UNIX the ^Z simply "disables" terminal I/O to the current process, and the "continue" operation simply re-enables it, there is no SIGSTP signal! > >Further, I think window systems are just fine, but they require VERY special >hardware to give acceptable performance. Job control frees up system resouces >by allowing processes to be swapped out. Window systems leave processes lying >around, and clutter the system even more with a window managing process! >The fact that a job can catch or not catch the SIGCONT as it pleases is a very >useful FEATURE! I would be very annoyed if somebody put screen control into >the kernel (!) and forces a screen update (expensive at 1200 baud) every time >I jumped into and out of a process. > >Don't clutter this group with off-the-cuff opinions and snorts! Both job >control and window systems have their place, and they can even work together. > Actually, a properly implemented windowing system should SIGSTP all processes not in active windows. And the window management system is best placed in the kernel where it does require a special process. My main objection to windowing is your last point - it requires to much in the way of special hardware to run correctly. In fact the 1200 Baud over-the-modem problem is *very* serious. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
faustus@cad.UUCP (Wayne A. Christopher) (04/08/86)
> Actually, a properly implemented windowing system should > SIGSTP all processes not in active windows. And the window management > system is best placed in the kernel where it does require a special > process. I don't think you really mean that first comment -- the whole point of having windows is so that you can have some things running in the background, and being able to see them while you're doing something else in the foreground. Also, I see no reason to put window management in the kernel -- X (which I consider the best available window system) has no problems running in user mode. Comments? Wayne
tim@ism780c.UUCP (Tim Smith) (04/09/86)
In article <2417@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: > I sure wish people would read before flaming. I sure wish people who lived in glass houses ... :-) > The original article was talking about SHELL LAYERS "shl" which > is a System V poor imitation of Berkeley job control. Shell layers is not an attempt to imitate job control! Shell layers is an attempt to solve the problem of multiplexing input to several processes. Job control seems to be a kludge attempting to solve multiple problems ( process control, input multiplexing, and output multiplexing ) all at once. > Under Shell Layers, a ^Z (or equivalent keystroke) passes the > terminal input to a different program, but the program that was > intercepted is not told, and is NOT EVEN STOPPED (output will > continue). Shell layers may be set up so that any process that attempts to do IO will block. Output in this case will not continue. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
hfavr@mtuxo.UUCP (a.reed) (04/10/86)
Sarima (Stanley Friesen) writes: > Actually, a properly implemented windowing system should > SIGSTP all processes not in active windows. I don't think that anyone who has used the asynchronous layering capability of AT&T windowing (5620,7300 etc) will agree with you. I want the process in the "deselected" layer - for example, a make which is running in one window while I am editing other code in another layer - to keep on writing so I can monitor it. This is the main reason why windowing increases productivity: so you don't have to stop your work just because you have to monitor the slow progress of some other process in real time. The cleanest conceptual model is that layers are just like separate terminals (in fact, I used to work with two terminals and a T-switched keyboard before I got a Blit). Are you going to claim that a process should behave differently depending on whether the user's keyboard is connected to its terminal? Adam Reed (ihnp4!npois!adam)
pdg@ihdev.UUCP (P. D. Guthrie) (04/11/86)
In article <1090@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > Actually, a properly implemented windowing system should >SIGSTP all processes not in active windows. Why would you want to do this? The beauty of a windowing system is the ability to monitor multiple running processes. Actually as we speak I am watching two interactive processes that I am testing. I couldn't do this properly without windows. I can generally do more than one thing at once and for my best productivity, I would like this to reflect on my computer usage. > And the window management >system is best placed in the kernel where it does require a special >process. Putting it in the kernel is a bad idea. The beauty of unix is that so much of the system software is *outside* of the kernel where it can be run and customized with much greater ease. No, the window system belongs to a great degree within a multiplexing process and inside the windowing device itself. > My main objection to windowing is your last point - it requires >to much in the way of special hardware to run correctly. In fact the >1200 Baud over-the-modem problem is *very* serious. >-- OK. I admit a good point, however we must consider the relative price of hardware. A DMD such as the one I am using now is rather expensive for the average user, but many other terminals also have at least simple windowing capabilities. My teletype 4425 has a 'windows' mode where it can have up to four windows and the scrolling is kept inside the window. I am currently (sporatically) working on a type of 'layers' for this. Most terminals made within the next few years will have this sort of capability, so it will become easier than ever to have 'windowing' in all environments, not just Unix. Yes, we should also have line modes for those who have 'older' terminals until these are all phased out, which should take a couple of decades. This really goes to show that large amounts of special hardware are not required and that terminal manufacturers are aware of this. I think it will become very important to them to produce the best windowing capabilities in their terminals for the lowest cost. AS for the 1200 (or god forbid 300) baud problem, you still have line (or I should say single screen) mode. No one is forcing you to use windows (and I often don't) but for most applications I find them more useful. > > Sarima (Stanley Friesen) > >UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen >ARPA: ttidca!psivax!friesen@rand-unix.arpa -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson
herbie@polaris.UUCP (Herb Chong) (04/12/86)
on further reflection, it is more likely that it was curses redisplaying
the screen.
Herb Chong...
I'm still user-friendly -- I don't byte, I nybble....
VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH
UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie
CSNET: herbie.yktvmh@ibm-sj.csnet
ARPA: herbie@ibm-sj.arpa, herbie%yktvmh.bitnet@wiscvm.wisc.edu
========================================================================
DISCLAIMER: what you just read was produced by pouring lukewarm
tea for 42 seconds onto 9 people chained to 6 Ouiji boards.guy@sun.uucp (Guy Harris) (04/12/86)
> Shell layers is not an attempt to imitate job control! From UNIX(TM) System V - System Release Description 2.0 - DEC(TM) Processors, April 1984, 307-006, Issue 1: 3. DETAILED FEATURE DESCRIPTIONS Job Control Job control gives users more control over their processes. It allows users to interact with different invocations of the shell, which can be conceptualized as shell "layers", only one of which receives input from the user's terminal at a time. ... The "shl" (shell layers) program is the user interface to the job control facility. ... This feature provides capabilities similar to BSD job control, but is a new implementation. ... For something which isn't an attempt to imitate job control, its description certainly uses the phrase enough times... > Shell layers is an attempt to solve the problem of multiplexing input > to several processes. Job control seems to be a kludge attempting to solve > multiple problems ( process control, input multiplexing, and output > multiplexing ) all at once. Shell layers, as you point out later, permits you to force all processes which attempt to do output when they're not the current layer to block. This sure sounds like an attempt to solve the input and output multiplexing problems all at once... > > Under Shell Layers, a ^Z (or equivalent keystroke) passes the > > terminal input to a different program, but the program that was > > intercepted is not told, and is NOT EVEN STOPPED (output will > > continue). > > Shell layers may be set up so that any process that attempts to do IO > will block. Output in this case will not continue. Yes, but what if the program isn't attempting to do output? What if, say, it's doing graphs on a VT100(TM) equipped with a board which provides Tektronix(TM) 4014 emulation, and has put the terminal in question in 4014 mode? How is the program running in that layer to know that it's layer is no longer the current layer, and that it should restore the terminal to normal mode? Then, when it becomes the current layer again, how is it to know that it's to put the terminal back into 4014 mode? Neither job control nor shell layers provides a perfect solution to the output multiplexing problem. Job control, at least, gives you hooks to put Band-Aids(TM) over some of the more obvious scars. If somebody tried to sell me a job control mechanism which forced me to clear the screen every time I suspended a screen editor, and forced me to type the "repaint the screen" key every time I restarted the screen editor, I'd show them to the door. I would find it unusable. (If shell layers does not require you to do this, somebody could do us all a great favor by explaining how.) To a large degree, this is a debate over matters of personal taste. People used to job control may argue in favor of it. People used to shell layers may argue in favor of it. I've got a window system, so most of the time I don't need either one. I occasionally move a job into the background retroactively. This is a convenience which I *could* live without. I *won't* do so, however, merely because somebody claims that job control is in bad taste - and that's what a lot of the anti-job-control claims amount to. (As for the question of "modifying lots of programs", somebody recently pointed out that many programs have *already* been modified in similar ways, for similar purposes - to support shell escapes.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
WANCHO@simtel20.arpa (04/14/86)
The ability to stop a process is a very nice features that is NOT
unique to BSD Unix (TOPS-10 and TOPS-20 had it).
Correction: TOPS-10 and TOPS-20 *have* it. So does MIT's ITS,
Stanford's WAITS, BBN's TENEX (and Tymshare's AUGMENT derivative of
TENEX)...
--Frankfriesen@psivax.UUCP (Stanley Friesen) (04/15/86)
In article <156@cad.UUCP> faustus@cad.UUCP (Wayne A. Christopher) writes: >> Actually, a properly implemented windowing system should >> SIGSTP all processes not in active windows. >> system is best placed in the kernel where it does require a special >> process. > >I don't think you really mean that first comment -- the whole point of having >windows is so that you can have some things running in the background >Also, I see no reason to put window management in the kernel -- X (which >I consider the best available window system) has no problems running >in user mode. Comments? > Several people seem to have misunderstood the first point, so I will attempt to clarify it. I didn't mean that *all* non-foreground windows should be considered inactive, only those that are interactive or are selected by the user for inactivation. That is, since BSD UNIX supports three classes of jobs, foreground, background, and stopped, so should the windowing system. Without all three a windowing system *doesn't* have the full capability of Job Control and I would therefor still require it. The second point was a quick "impression" giving few details. After giving the matter more thought what I would like see is for the low level primitives for managing windows to be placed in the kernel. That is the ability to create, update, and display windows should be part of the I/O system, preferably as extensions to the tty device drivers. Then the window session manager would be implemented as a user mode program. In fact it should be integrated with the command interpreter to produce a Window Shell. This way you get a single login process, a unified history mechanism and an integrated control interface. You also get the ability for user programs to create and manipulate windows if they need to. (P.S. subshells should probably be "normal", non-windowing shells running in thier own window). -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
aglew@ccvaxa.UUCP (04/15/86)
[Comment:] I find the term `shell layers' inappropriate. It seems to imply, to me, subshells, perhaps not even tree structured. When I think of multiplexing on a wire I do not think of layered sets of data, with this layer being above or below that - I think of a switch. The term `layers' is really only appropriate to an aspect of the implementation, in terms of (overlapping) windows. [Has anyone ever made a non-layered windowing system - one where you can get cycles of overlaps? Wouldn't work with rectilinear windows.] [Question:] does the `shell layering' system include true virtual terminals mapped into a memory image of the screen display? If so, nice, but could quickly start consuming large amounts of memory (say I want to have N 1Kx1K colour maps, but I'm only displaying the equivalent of 1.5 at any time). Is there provision for less storage costly alternatives - a window resized or revisibled interrupt? Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms