greg (11/12/82)
We are running 2.8BSD here and I would like to incorporate the job control facilities of 4.1 in it. Does anyone have pointers as to where I can get the appropriate kernel/csh/? mods? I do NOT want to upgrade to 2.81 or 2.9 if possible. I've gone through 2 upgrades this year already. Thanks for any info, Greg Travis decvax!pur-ee!isrnix!greg
dmr@dutoit.UUCP (04/12/86)
Here are a few thoughts about windows, job control, and elegance vs. hackery. It seems to be granted by everyone that windows, especially on good terminals, are desirable, and there is consequently some boasting and envy on the part, respectively, of the haves and have-nots. These feelings are real, but unrelated to the technical considerations. The inherent advantage of a window system, on a suitable terminal, over job control is that it lets you have spatial separation of several independent conversations. On an ordinary text terminal, the windows are perforce either very small (as in emacs, for example) or are time-multiplexed on one screen (as in BSD and also AT&T job control). Otherwise, though, the two notions share much, and similar approaches to them can be useful. The underlying problem that has to be solved in the system and the user-level software is how to manage the several separate computations and their IO. BSD job control does this by pushing hard on the idea of process groups: separate jobs have different process groups, and the various drivers check flags that get set by signals sent to the appropriate group. In this way, job groups have their IO and CPU demands controlled so that they don't interfere on the screen. This is orchestrated by special coding in csh. All the jobs are talking to the same terminal. The total amount of code in the kernel is not terribly large, but it is spread widely and much of it is frank special pleading (E.g. the comment in sig.c: "Children of init aren't allowed to stop on signals from the keyboard" annotating code that turns SIGTSTP, SIGTTIN, and SIGTTOU into SIGKILL if the parent is process 1. This from 4.1.) 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. The virtual terminal seen by each job has its own instance of the tty driver; for example, you can turn off echo in one job (or window) without affecting another. Of course, neither shl, nor BSD job control, knows anything about the real terminal: what is on the screen or any special modes the terminal itself might be in. How should we judge these offerings? It seems to me that the the V8 and the SV mechanisms are cleaner because they create a more natural separation between independent jobs than having a particular shell scatter lightning bolts in the form of signals and process group manipulation. They generalize better, and they provide the service less clumsily: shl is a pseudo device driver, and the V8 implementation falls automatically out of its IPC. However, conceptual superiority doesn't guarantee that the effect will be better. The mutterings over SIGTSTP start to show this. It seems perfectly plausible that a signal should be available to a program that might want to redraw its screen when its job was unblocked or window reshaped, and there was nothing preventing shl from generating it. In theory, BSD job control is much more of a wart on the system than the SV shl idea. In practice, provided that you are willing to use csh, or more recently ksh (and I'm not), the BSD scheme is easier to use. It is always there, at the touch of a key, and it works. My impression is that BSD job control is something that was put in by expedient means in order to achieve a certain effect, and the effect is excellent, within the serious limitations of the mechanism. SV job control was done with a cleaner conceptual foundation, but with a less lucid view of what it is for, and less effort devoted to making it useful. Indeed, I suspect it is not much used. For example, on the SV machines run by the local comp center, shl is available, but doesn't work (it hangs your terminal) when you come in via the network instead of a dial-up or hard-wire. Dennis Ritchie
MRC%PANDA@sumex-aim.arpa (Mark Crispin) (04/15/86)
I hope that people who are in a position to influence the course of
development of the Unix user interface are listening to the issues being
presented and especially the comparision with TOPS-20 job control. I've
encountered a lot of "NIH" when trying to lobby for this sort of feature
in Unix. The argument goes like this: TOPS-20 is "obsolete", Unix is not,
therefore there is no reason to adopt anything from TOPS-20.
Here's a couple of other things from my wish list. The Unix manuals
need to be *completely* rewritten by somebody who knows how to write
technical documentation. Unix documentation rivals Interlisp documentation
(guess what two systems I've been using a lot lately?) in its generally
poor quality and disorganization. The indices are next to useless.
As an example, here were two questions I had recently. First, I wanted
to know how to find out what the Unix system thought was terminal type and
its parameters were (the TOPS-20 INFORMATION TERMINAL command). I knew that
the magic "setenv TERM terminal_type" would set it, but I couldn't find a
corresponding getenv command or any help under keywords "setenv", "term",
"stty", etc. etc. I still don't know how to do this. Second, I wanted to
know how to set the width and height of my terminal. My terminal type may
be "VT100", but it's a terminal emulator on a Lisp machine and the window
I draw is 62x116. Another reason for setting the width is that we use the
same terminals on TOPS-20 and Unix. On TOPS-20, software will output an
automatic newline at the end of the line so you do *not* want to set auto
newlines in the terminal hardware. I wanted to get software newlines on
Unix as well. My local guru said "it can't be done"...(another wish list
item!).
-------gwyn@BRL.ARPA (VLD/VMB) (04/15/86)
echo $TERM to print the current value of the environment variable TERM. (This is explained in almost any UNIX tutorial.) env prints the entire current environment (UNIX System V; use "printenv" in Cshells). Terminal descriptions are contained in /etc/termcap or the terminfo equivalent (SVR2 only). This database is indexed by the value of TERM; if you claim to be using a "vt100", then the description for a DEC VT-100 is used. By gum, a DEC VT-100 does NOT have 62x116 character positions. To get the 62x116 terminal described, have an entry with a new name added to /etc/termcap, e.g. xx|crispin|Crispin's magic terminal:\ :co#116:li#62:tc=vt100: Another approach, if your system supports it, is to set the window size information into the kernel data structure associated with the terminal, via TIOCSWINSZ or equivalent. This overrides the screen size info from /etc/termcap and is (0,0) until specifically set. Windowing systems should update this information for each pseudo-terminal automatically. Your system administrator really should know all this and be able to set up your login state appropriately.
ed@mtxinu.UUCP (Ed Gould) (04/15/86)
>SV job control was done with a cleaner conceptual foundation, but with >a less lucid view of what it is for, and less effort devoted to making >it useful. Indeed, I suspect it is not much used. I was told at the Washington, D.C., Uniforum, by someone from AT&T who claimed to have proposed the shl idea, that he was *joking* when he suggested it. I believe that he was. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
gwyn@BRL.ARPA (VLD/VMB) (04/15/86)
I certainly agree that UNIX, at the level you are talking about (direct use of the shell, etc.), is not designed for casual use. It was designed specifically for software development, and anyone peddling this interface for naive, untrained users is guilty of a (minor) crime. Unfortunately, the original precise, compact documentation for the computer professional has now been spread across nearly 10 times as many manuals and has been buried under the "computer will not listen to you until you press RETURN" style of naive-user instruction that you referred to. I think AT&T has mixed the two rather different categories of users into the same basket, to the detriment of both. On the other hand, I'm sure that if I attempted to use TOPS-20 with UNIX experience as a guide and didn't read the explanatory material first, I would get just as annoyed with it as you seem to be with UNIX. (In fact, in my few brief encounters with TOPS-20, it was pretty puzzling. If I had to use it for serious work, though, you can bet I'd read the documentation first.) There's room for both TOPS-20 and UNIX, but I wouldn't advertise either as having an ideal general-user interface.
bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (04/16/86)
Re: Unix doc, Tops-20 pilferage et al Remember that a major feature of the UNIX documentation has always been that it is designed to be kept entirely on-line, this requires some compromises in organization (which I personally think aren't too bad.) I have seen a few vendors try to 'fix' the documentation in various ways and every one of them first forsook (?!) on-line documentation which I promptly called them and screamed my little head off about. Something I did not understand from your note is: do you want more indexing in the on-line set or the printed set? Which were you having trouble with? (not that I have anything to do with this, just asking.) People have INFO-ized the UNIX manual (I did it once, quite a chore but it worked), would this help or maybe what you really need is a good KWIC index? At any rate, I don't see anything particularly wonderful in the TOPS-20 documentation that solves any of this, for example, except perhaps the operations manual which is quite well done. My question is basically do you need better on-line programs to search the docs (write one! that's all we ever do and submit it to the world for acceptance), or actually different dead-tree style. Speaking of TOPS-20, I think you are unfair to accuse UNIX of honesty. I think UNIX has stolen shamelessly over and over again and is proud of it, I pluck your beard sirrah! What is your reaction to the TIOCSTI call (emphasis on STI)? How about the tcsh with command completion? The inheritance of groups through directories? The standardization of TCP (I know, low blow, but let's face it, that was w/in the domain of TOPS-20, I seem to specifically remember a memo going around back in the early 80's or maybe late 70's that specifically was debating whether to move from TOPS-20 to UCB/VAX/UNIX for standard DARPA implementation, the memo I believe originated from somewhere in DARPA.) My point is only that their historical growth has been close and there has been no particular lack of cross-semination, albeit with keeping to their own particular styles. (hmm, how about the ability to suspend shells and the apology you get if you try to suspend [read: detach] your login shell?) etc etc. -Barry Shein, Boston University
MRC%PANDA@sumex-aim.arpa (Mark Crispin) (04/16/86)
Barry -
The online documentation needs a good KWIC index, and the
hardcopy documentation needs a real index, e.g.:
TERMINAL
hung terminals, fixing 844
interconnection 223
reading parameters 111, 143(fn), 432
setting parameters 113-116, 124, 322
using terminals as a device 53-55
Basically, *every time* some technique is described, it
should get an index marker. I have no idea if troff or nroff or
whatever is in vogue can do this; if not dump it and use a real
document formatter such as Scribe.
Look in any well-organized reference manual index or even
better, look at any history book with indices and footnotes.
Such things can be done; it just takes a person with more than a
6th grade education in writing skills and the English language.
Yes, many hackers are functionally illiterate, but I know that
isn't the universal case.
There really isn't much of a comparision between the
TOPS-20 documentation and Unix. There's too much TOPS-20
documentation (it needs 5 strong men to carry all of it), and
very little of it is available online. Most TOPS-20 programs are
intrinsically self-documenting, which helps. And, equally
important, most TOPS-20 manuals have a REAL index! Since the
Unix documentation is so small, it should be possible to index
the entire documentation set.
-- Mark --
-------mwm%ucbopal@ucbvax.berkeley.edu (04/17/86)
> It's somewhat distressing to hear that I have to know what sort of > Unix system I'm on so I don't use "env" when I should use "printenv". > I would be a lot happier if I heard that "printenv TERM" would work as > a replacement for "echo $TERM". Uh, sorry, Mark, but which of env/printenv/echo works depends on what command line interpreter you're using, as well as what Unix you're using. Just ask how to find the terminal type on a v6 system :-). The ability to use your favorite CLI is a win. You have to expect that things that change/print/otherwise-diddle the internal data structures of the CLI will change as you change CLIs. For the most part, they stay constant across different flavors of Unix if you stay with the same CLI. Now, what you shouldn't ask is how the terminal type information got imbedded into the CLI on Unix. "Unix is rapidly replacing obsolete 10 to 15 year old OS's." <mike
friesen@psivax.UUCP (Stanley Friesen) (04/18/86)
In article <2113@dutoit.UUCP> dmr@dutoit.UUCP writes: > > In none of these is a special >shell needed. The virtual terminal seen by each job has its own >instance of the tty driver; for example, you can turn off echo in one >job (or window) without affecting another. Of course, neither shl, nor >BSD job control, knows anything about the real terminal: what is on >the screen or any special modes the terminal itself might be in. Is there only one shell running per login session, rather than one per window? If the former, how does it manage selecting/deselecting windows without special code? If the latter, I consider this a very inefficient implementation. My ideal would be a system with a single instance of the shell per login session which creates the windows and handles the switching operation in a manner that is fully integrated with the command line parsing operation. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
jso@edison.UUCP (John Owens) (04/21/86)
> I was told at the Washington, D.C., Uniforum, by someone from AT&T > who claimed to have proposed the shl idea, that he was *joking* > when he suggested it. I believe that he was. > -- > Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA "shl" seems to be a lot like the old TOPS-10 OPSER program, which would create numerous subjobs, all of which could be controlled by the top-level program, which was most often run from the (hardcopy) console terminal. Output from each program was preceeded by its job number, and the user would direct input to the program he wanted by its job number. (I think you could also have names as aliases for the numbers.) It also handled various operator-like functions directly. Of course this program is useless for anything but hardcopy terminals and glass ttys.... John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]
ron@BRL.ARPA (Ron Natalie) (05/01/86)
Oh pooh, MARK. Large portions of the TOPS-20 manuals have no index or the one is equally useless. I dug through each manual in the 20+ binders and could not find one entry that says referenced anything vaguely recognizable as a description on what you had to do to get TOPS-20 to comply with the RS-232 spec by actually asserting DTR. -Ron