henry@utzoo.uucp (Henry Spencer) (10/10/89)
In article <3630@solo5.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >Job control. Henry Spencer wrote you didn't object to it *in principle*, >but to the POSIX standard. Perhaps some other scheme would do... Well, I don't think I put words in Andy's mouth in quite that way -- I didn't intend to -- but if you think you can come up with a scheme that is simpler than the one in POSIX, you should try. The whole approach is just plain wrong; when you try to define it carefully and make sure it doesn't cause trouble anywhere, the result is inevitably complex and messy. The one in POSIX is probably better than any straightforward alternative, alas, unless you scrap the whole concept and start over. Unfortunately, everyone has been so besotted with the original abomination that there has been very little work on alternatives. (This would probably make a good research topic for some ambitious folks. I'd suggest starting with a basic principle: the job-control system should manage both input and output, so that no program needs to be modified to know about job control and it is the job of the system -- not the user or the programs -- to refresh the screen when switching from one process to another.) -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tuna@athena.mit.edu (Kirk 'UhOh' Johnson) (10/10/89)
(humor: the old subject of this thread was "Re: Important new program:
cleanit.c". guess people don't look at their Subject line much ...)
In article <3631@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
% Personally, I think a far better and more elgant solution would be
% virtual screens. You simulate N terminals on one. When you hit
% ALT-n, the contents of the screen and replaced by that of terminal ,
% and the keyboard is attached to terminal n. In effect, you are
% timesharing the one screen into n windows. Again, the trick is
% localize everything so that there are no tentacles all over the
% place. It won't be easy.
this is the solution used in the version (2.1) of IBM's AIX i worked
with (on a PC/RT model 125). the thing i didn't like about their
implementation was that there was no easy way to tell how many of
these "virtual terminals" one had running, nor what they were actually
running.
with job control, i can say "jobs" and find out how many stopped jobs
i have and find out what they are doing. further, i can start up any
one of them i want with one simple command. in the AIX version of your
proposed solution, i could do neither. i could only cycle through my
entire set of active terminals, one at a time; this definitely had a
negative impact on the "usability" of the multiple virtual terminals
concept. BSD-like job control, in my eyes, is much nicer to use.
i think a reasonable interface must allow the user to
(1) find out how many virtual terminals are "active" (and also
find out what each of those terminals is running)
(2) switch to an arbitrary one of those virtual terminals with one
simple command/keystroke
can such an interface be added on top of the multiple virtual
terminals idea with out introducing the same kind of complexity
introduced by job control?
is anybody out there actively working on this issue? or is it
primarily an idea that is just being thrown around?
kirkpeter@ficc.uu.net (Peter da Silva) (10/11/89)
I'm using System V/386 right now, with virtual terminals. [how do you] > (1) find out how many virtual terminals are "active" (and also > find out what each of those terminals is running) % ps -ef | grep ' vt.. ' root 27520 1 2 18:19:01 vt01 0:03 -csh root 162 1 0 Sep 28 vt02 0:03 -csh peter 27515 1 0 18:18:58 vt03 0:02 -csh peter 27510 1 0 18:18:52 vt04 0:02 -csh root 29000 27520 12 13:30:25 vt01 0:00 /bin/ps -ef root 29001 27520 2 13:30:25 vt01 0:00 /bin/grep vt peter 28409 27515 0 10:30:54 vt03 0:08 /usr/bin/vt xds13 peter 28410 28403 0 10:30:55 vt04 0:51 kermit -l /dev/tty00 -b 9600 peter 28411 28409 0 10:31:00 vt03 4:05 /usr/bin/vt xds13 peter 28402 27510 0 10:30:49 vt04 0:00 /bin/sh /usr/local/bin/tty00 peter 28403 28402 0 10:30:50 vt04 0:04 kermit -l /dev/tty00 -b 9600 root 28744 162 0 11:52:08 vt02 0:02 /usr/bin/rlogin sigma root 28745 28744 0 11:52:10 vt02 0:33 /usr/bin/rlogin sigma % alias vps "!!" % who | grep ' vt.. ' peter vt04 Oct 10 10:30 saver peter vt03 Oct 10 10:30 saver rootc vt01 Oct 10 11:41 saver rootc vt02 Oct 10 11:48 saver % alias vwho "!!" > (2) switch to an arbitrary one of those virtual terminals with one > simple command/keystroke SysReq-F<n> goes to vt0<n>. > can such an interface be added on top of the multiple virtual > terminals idea with out introducing the same kind of complexity > introduced by job control? Obviously. > is anybody out there actively working on this issue? Looks like it. One caveat, if you're working on a remote terminal you want to be able to specify some sort of multiplexing, so you don't have to repaint the whole screen when you shift to a new process. You could have vt01, vt02, and vt03 sharing the same virtual screen. Then vt04 and vt05 would have a new screen. You could select 1, 2, or 3 without a repaint, and output from the ones not currently active would be held until they were selected. Or not. Sounds like a job for Emacs to me. (1/2 :->) -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` Quote: Structured Programming is a discipline -- not a straitjacket.
henry@utzoo.uucp (Henry Spencer) (10/11/89)
In article <14987@bloom-beacon.MIT.EDU> tuna@athena.mit.edu (Kirk 'UhOh' Johnson) writes: >% Personally, I think a far better and more elgant solution would be >% virtual screens... >this is the solution used in the version (2.1) of IBM's AIX i worked >with (on a PC/RT model 125). the thing i didn't like about their >implementation was that there was no easy way to tell how many of >these "virtual terminals" one had running, nor what they were actually >running. These are details of implementation rather than flaws of concept. Not that the details don't matter to the users, mind you -- those are significant defects -- but they are the sort of things that a good implementor could fix in half an hour. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
news@bbn.COM (News system owner ID) (10/12/89)
henry@utzoo.uucp (Henry Spencer) writes:
< (This would probably make a good research topic for some ambitious folks.
< I'd suggest starting with a basic principle: the job-control system
< should manage both input and output, so that no program needs to be
< modified to know about job control and it is the job of the system --
< not the user or the programs -- to refresh the screen when switching
< from one process to another.)
Amen. Esp. to the tty state stuff. Garbage like tcsh has to do
(automatically restoring a sane state to the tty driver) should not be
needed at all.
I'd also add a not-so-radical concept from Tops-20 (and predecessors),
CMU's tty hacks, etc.: one should be able to change the controlling
tty of a stopped process transparently. As I understand them, the CMU
hacks seperate the upper and lower halves of the BSD tty driver, so
that a pair can be glued together on the fly. This method is pretty
(OK, _really_) ugly, though. More room for improvement.
< A bit of tolerance is worth a
< megabyte of flaming.
Amen to that too.
-- Paul Placeway <PPlaceway@bbn.com>