bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (04/14/86)
>From: dmr%dutoit.uucp@BRL.ARPA >In the Eighth Edition and also in the System V shl mechanism, each job >communicates with one of a set of virtual devices multiplexed onto the >real device. In SV the multiplexor is in the kernel and is quite >simple; mainly it just blocks IO from background jobs. In V8 it is a >user-level program that talks to an educated terminal. In SV with 5620 >support, the multiplexor is again a kernel program similar to that used >by shl (though the the multiplexor is more complicated because it >speaks in protocol to the terminal). In none of these is a special >shell needed... Although the point is technically correct, the program which manages shell layers, shl.c, is effectively equivalent to that part of csh which does job control brought out to another (meta) process. A quick reading of shl.c should be fairly disturbing to most anyone (I seem to remember a portion where output is put to a pipe to the child fork to determine whether it has started yet and hence 'safe' to do the ioctl()s.) I'm not sure all that magic is particularly 'cleaner' than anything I see in 4.2, and without the source to that program or a hint about how this is done it's nearly impossible for a mere mortal to figure out how to program their own equivalent of shl.c just by the ioctl descriptions. Sorry if there are any minor errors here but my 3B5 is, as usual, dead. Maybe the pipe went the other way (parent hung on read, fork wrote upwards.) I think TOPS-20's ^C had the right idea, basically it is the same as a BSD ^Z (TSTP) but unless you do something to save the fork (KEEP cmdname) it is replaced by the next command thus preventing naive users from backing up a lot of stopped jobs, no one mentioned this problem on BSD, anyone else have students with 15 stopped lisps because it doesn't stop when they hit ^C but ^Z works "just fine"?! Effectively, there is no ^C in the UNIX sense on TOPS-20, only ^Z as I describe. (obviously this could be controlled by a shell variable.) Not sure if this has anything to do with window systems though, I suspect in the end they will push for their own solutions beyond just extrapolations of current features, otherwise it's the tail wagging the dog. The point of a window system is, ultimately, to make the user's life easier, not to show how some current 'job control' can be pushed to its limits. -Barry Shein, Boston University
rcodi@yabbie.OZ (Ian Donaldson) (04/17/86)
> ... replaced by the next command thus preventing naive > users from backing up a lot of stopped jobs, no one mentioned this > problem on BSD, anyone else have students with 15 stopped lisps > because it doesn't stop when they hit ^C but ^Z works "just fine"?! ... > -Barry Shein, Boston University Its funny you should mention that - lots of our students seem to do exactly the same thing - hit ^Z instead of ^C as it "works". They then wonder why the system starts slowing down, or it always says "There are stopped jobs" when they log out. I think that the word "Stopped" is rather inappropriate. "Stop" to me means halted or dead. I think that the word "Suspended" should replace the word "Stopped" (in csh and all related literature), as it gives a notion that there is still something there that can be restarted. Ian Donaldson ACSnet: rcodi@yabbie UUCP: ...!siesmo!munnari!yabbie.rmit.oz!rcodi CSNET: rcodi@yabbie.rmit.oz ARPA: rcodi%yabbie.rmit.oz@seismo BITNET: rcodi%yabbie.rmit.oz@CSNET-RELAY VOICE: +61 3 660 2619, 1pm-11:59pm weekdays PAPER: Dept of Communication & Electronic Engineering, Royal Melbourne Institute of Technology, Latrobe St, Melbourne, 3000, Australia (used to be rcodi@Unison6)
rjk@mrstve.UUCP (Richard Kuhns) (04/17/86)
In article <2619@brl-smoke.ARPA> bzs%bostonu.csnet@csnet-relay.arpa writes: > >[...] it's nearly impossible for a mere mortal to figure out >how to program their own equivalent of shl.c just by the ioctl descriptions. > Agreed. Now, has anyone actually used these ioctls? I'm working on a couple of applications where some of the capabilities of the so-called 'virtual ttys' would come in very handy, but I can't figure it out from the manual page (sxt(7)), and AT&T has been less than no help. Any working code fragment, or suggestions as to where to look for more info, would be greatly appreciated. I will, of course, summarize to the net if anyone else is interested. -- Rich Kuhns {ihnp4, decvax, etc...}!pur-ee!pur-phy!mrstve!rjk
oz@yetti.UUCP (Ozan Yigit) (04/19/86)
In article <2619@brl-smoke.ARPA> Barry Shein writes: > >Not sure if this has anything to do with window systems though, I suspect >in the end they will push for their own solutions beyond just extrapolations >of current features, otherwise it's the tail wagging the dog. The point of >a window system is, ultimately, to make the user's life easier, not >to show how some current 'job control' can be pushed to its limits. > > -Barry Shein, Boston University This is (in my opinion) a very important point: There is only so much *retrofitting* an operating system can take, without fairly major re-thinking and re-design of the kernel. If this is not done, the end result is various abominations UN*X factions love to hate: shell-layers etc. for berkefolk, and signals, csh, job-control for sys-?-folk. Compatibility with earlier versions of UN*X is a nice ideal, but when it starts to exert a heavy price from the system, or from its users, things will have to be re-designed, perhaps at the expense of compatibility. To illustrate a point: would you write/use a filter for troff that handles TeX & LaTeX input, and tries to typeset an approximation, knowing full well troff "engine" is not powerful enough to handle TeX way of doing things, and it simply has to cludge its way ?? Does one have to live with restrictions like "well, we could almost do that, but frobotz will overflow if you do bar, and you have to include gawgaw to get a similar layout" ?? This simply means that there is a *limit* to how much one can retrofit troff, without re-thinking major parts of its typesetting algorithms, and the way it handles its commands etc. The same thing applies to UN*X as far as process control, window management etc. considered. The berkeloids *did* re-think the way things are handled in the UN*X kernel, and added signals. While many considers this a major hack, it had to be done, just like kernel had to be modified to get vmun*x !! (would you like to implement a virtual memory system with pipes and forks, just so that kernel remains as simple as before, and somehow compatible ? :-) [note that I am not saying they did *the right thing*, all I am saying is that they were on the *right track*] Perhaps it is time to consider when UN*X (vanilla versions) stops being *as simple as possible* and becomes *simpler*. [and he falls from the soapbox, into the hands of the angry audience.. nobody yet claimed responsability for the resulting mayhem..] oZ -- Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz Bitnet: oz@[yusol|yuyetti] Join USAGUR [USers AGainst Un*x Retrofitting] and support GNU [the alternative].