Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!ucbcad!nike!sri-spam!rutgers!im4u!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: job control
Message-ID: <5932@ut-sally.UUCP>
Date: Mon, 6-Oct-86 19:15:47 EDT
Article-I.D.: ut-sally.5932
Posted: Mon Oct 6 19:15:47 1986
Date-Received: Tue, 7-Oct-86 03:43:00 EDT
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Lines: 272
Keywords: POSIX Appendix C
Approved: j...@sally.utexas.edu
From: pyramid!utzoo!he...@sally.utexas.edu (Henry Spencer)
Date: Sat, 4 Oct 86 03:03:30 PDT
After some activity back when the Unix standard was with /usr/group, I've
"gone dormant" on standardization work through lack of time. I haven't
even seen most of the P1003 stuff. However, I understand that there is
a proposal to incorporate Berklix-like "job control" into P1003. Given
the interest in getting some new topics into mod.std.unix, I'm submitting
the following. It's a slightly touched-up version of a paper Ian Darwin
and I submitted to the /usr/group standards effort, arguing strongly that
neither 4BSD "job control" nor SysV "shell layers" should be incorporated
into a standard. Since I haven't seen the detailed P1003 proposal, it's
possible that some of this is out of date, but on the whole I think it's
of interest nonetheless.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
[ Perhaps whoever has the original online copy of the current P1003
proposal could submit it? That would probably be worthwhile even if
it had to be broken into several articles for space reasons. -mod ]
Comments on Terminal I/O, Specifically `Job Control'
Henry Spencer
University of Toronto
utzoo!henry
Ian Darwin
University of Toronto
utcsstat!ian
`Job Control', What It's Really About
There is no longer any argument that it is desirable to permit orderly
user interaction with multiple processes. Unfortunately, a whole generation
of Unix users has had their view of this concept warped by the dreadful way it
was implemented by Berkeley. And AT&T, in its recent attempt to address the
problem, has taken the easy way out instead of doing it right.
The basic concept involved here is multiplexing, not `job control' or
process suspension. The ideal is something like the environment on the Bell
Labs Blit, where multiple processes run simultaneously in multiple windows,
and the user can switch his attention and his interaction from one to another
at will. There is a popular misconception that doing this *requires* a Blit
or a similar highly-intelligent terminal; this is simply not true.
Window-based multiplexed interaction is harder to do when the terminal is
dumb, but even the Blit is not actually writing things into several windows
*simultaneously*: it just looks that way because of the high-speed multiplex-
ing involved. There is no intrinsic reason why this multiplexing cannot be
done at the other end of the communications line when the terminal is incapa-
ble of doing it.
The multiplexing can be done in the kernel (albeit at considerable cost
in added kernel complexity) or in a user process (given suitable interprocess
communication). In either case, the fundamental structure is quite simple: a
central `manager' coordinates terminal i/o to and from `client' processes,
each of which has total control of its own "virtual terminal". The manager's
job is simulating multiple virtual terminals on a single real terminal, by
routing input to the appropriate process and placing output in the appropriate
area of the screen.
- 2 -
The basic characteristics of such a multiplexing system are that each
process has what looks (to it) like a private terminal, and that all i/o to
and from the user is centrally supervised. This is precisely analogous to
file i/o under Unix: simultaneous independent activity by multiple processes,
coordinated by a central manager which multiplexes physical resources so as to
prevent interference. The benefits are similar: individual processes neither
know nor care about the multiplexing, and useful high-level abstractions can
be implemented in one central place.
Job Control and Layers: Half-Baked Approaches
The existing schemes, Berkeley `job control' and AT&T `layers', unfor-
tunately are clumsy and incomplete attempts at implementing multiplexed
interaction. Neither one makes any provision for simultaneous on-screen
activities by more than one process, except for the `cop-out' of permitting
multiple processes to intermix their output at random. But there are deeper
problems.
Both schemes require that *every* *program* which is going to participate
in multiplexed interaction must contain code to allow for this possibility!
User programs must be prepared to redraw the screen on request, with the
requests coming from the kernel in the Berkeley scheme and from the user in
the System V.2 scheme. This is an abomination.
Not only does this demand specialized code in every user program, but it
entirely denies multiplexed interaction to the bulk of Unix programs. The
concept of `redraw the screen' is meaningful only for interactive programs
with full-screen interfaces. The result of, say, an *egrep*, once replaced
on-screen by (say) the editing buffer of a *vi*, is gone for good. Since
*egrep* is not an interactive program, it is no longer around to be asked to
redraw its output.
The heart of the problem is that neither job control nor layers imple-
ments the crucial half of a window system: centralized management of screen
updates. It has long been accepted that multiple processes cannot safely do
updates to disks without centralized management and consistency control. The
same obviously applies to terminal i/o: orderly simultaneous interaction with
multiple processes requires centralized supervision of the interaction. The
existing schemes supervise input but not output.
It is obvious *why* this deficiency exists: supervising output is the
hard part. The idea of switching input from one program to another is reason-
ably straightforward. Differences in input handling, such as `cooked' vs.
`raw' modes, are relatively minor problems, since the user can be conversing
with at most one process at a time. But a CRT terminal permits output from
multiple processes to be displayed simultaneously, and coordinating screen
updates isn't trivial. Furthermore, there is no agreement on the precise user
interface that should be presented for output -- consider, for example, the
religious debates over overlapping vs. non-overlapping windows -- and this
discourages attempts to provide a single and relatively inflexible central
solution. The immense variation in CRT-terminal control sequences puts the
icing on the cake.
- 3 -
Nevertheless, these problems *can* be solved. There are at least three,
and probably several more, complete window systems in experimental use. Some
of them have performance problems, and most of them are outside the kernel and
hence have interprocess-communication problems, but they do work.
Standardizing Multiplexed Interaction: A Recommendation
As mentioned above, several experimental window systems already exist.
(This is quite apart from the `real' window systems on bitmapped workstations,
which are also relevant.) Experience with these and other implementations of
the same concept will yield a wealth of knowledge on how best to handle this
function. It is important that this experimentation, and the adoption of the
results that come out of it, not be stifled by further `official endorsement'
of incomplete and badly-designed existing schemes.
The best approach for P1003 to take on this matter would be to reserve
some characters, and some flag bits, for implementations of multiplexed user
interfaces, but not to specify any such interface at this time. Such an
attempt to specify the interface would be premature, especially when the two
approaches under consideration are already known to be grossly-incomplete
botches.
*Neither Berkeley `job control' nor AT&T `layers' is an adequate imple-
mentation of a multiplexed user interface*. *Neither one should be cast in
concrete as a standard at this time*.
A Retraction
Our previous recommendation was that, if multiplexed interaction *must*
be standardized, AT&T `layers' would be a better place to start. The layers
system, unlike Berkeley job control, does do input multiplexing more-or-less
correctly, and hence is essentially upward-compatible with true window sys-
tems. It has several desirable characteristics: independent tty state for
each layer, suspension/resumption invisible to the processes, a central
manager process which is *not* imbedded in a shell, and an implementation that
does not have ramifications everywhere.
Nevertheless, as discussed above, it doesn't do the hard part: output
multiplexing. It also has some annoying implementation limits, which,
although they wouldn't necessarily have to propagate into a standard, might
well propagate into most early implementations. Its major problem is that
it's not clear how to extend it to centralized output management without
imbedding said management inside the kernel.
We therefore retract our recommendation for standardizing layers as a
second choice. The proper course is to standardize nothing, at least until we
understand the user-interface issues and the implementation problems better.
Specifics
A decision not to standardize a multiplexed-interaction scheme notwith-
standing, there are a few useful minor things that can be standardized. The
*termio* structure probably should have a reserved character or two (or room
for same) and a few reserved bits (or room for same) to permit kernel-based
- 4 -
implementations of multiplexing.
In particular, almost any multiplexing scheme using ordinary ASCII termi-
nals will need a special character to attract the attention of the multiplex-
ing software. Without this, it's very difficult to do things like moving
between windows. Reserving space for such a character might be useful; recom-
mending a default choice for the character would be very valuable, as it would
forestall unnecessary differences between implementations. Control-Z would be
plausible.
Implementing supervision of multiplexed interaction in user processes is
difficult in many existing Unix implementations, minimal implementations of
the existing P1003 standard among them. The basic problem is that normal user
processes are definitely aware that their output is going to a terminal, the
device-independence of Unix i/o notwithstanding. Screen-oriented programs
doing *ioctl*s are the biggest problem. A less obvious glitch is that *stdio*
adjusts its buffering strategy depending on whether output is to a terminal or
not; this is a major nuisance with some existing window systems. Something
like the `pseudo-tty' concept would be very useful: an entity which looks
like a terminal from one side, but whose behavior is under user-process con-
trol from the other side. Some existing systems do implement such things, but
the lack of standardization largely prevents use of them in portable programs.
Suspending Processes: A Non-Issue
Several people have objected to AT&T layers, and similar approaches, on
the grounds that `...but 4BSD lets me suspend misbehaving processes...'. This
is silly; a process-suspension facility can be very simple if it isn't
required to double as a multiplexing system.
If it is thought desirable to standardize process suspension, we would
suggest the following. Some magic character (control-Y?), when typed as input
to a tty/window, suspends all processes attached to that tty/window. The
suspension can be, and should be, utterly invisible to the processes involved.
This avoids the sticky problem of how to notify the processes without doing
incompatible things to the *signal* mechanism. The suspension probably should
have a permission requirement analogous to that of signals: if the effective
userids of the user and the process don't match, the suspension doesn't hap-
pen. This is necessary to prevent major security breaches like suspending
*passwd*(1) in the middle of an update to the password file.
Note that this suspension facility isn't very useful in the absence of
multiplexed interaction -- you can't *do* anything to a suspended process
without access to another (real or virtual) terminal -- but the two concepts
are nevertheless quite independent. There is no need to confuse them.
Volume-Number: Volume 7, Number 30
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <5965@ut-sally.UUCP>
Date: Thu, 9-Oct-86 12:25:20 EDT
Article-I.D.: ut-sally.5965
Posted: Thu Oct 9 12:25:20 1986
Date-Received: Fri, 10-Oct-86 00:49:46 EDT
References: <5932@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 58
Keywords: POSIX Appendix C
Approved: j...@sally.utexas.edu
From: cbosgd!cbosgd.ATT.COM!m...@seismo.css.gov (Mark Horton)
Date: Thu, 9 Oct 86 01:30:59 edt
Organization: AT&T Bell Laboratories, Columbus
I've made significant use of four different sorts of systems
for multiplexing, so hopefully I can provide some feedback on
their relative merits, from a user's point of view.
(1) True windows, such as a 5620, Sun, UNIX PC, etc. Each window
acts like a terminal. This is unquestionably the best, but it
requires special hardware, and is an area that needs to be
standardized.
(2) A dumb-terminal window manager as Henry describes. I've written
such a window manager; on a system that has ptys, select, and a smart
curses package, it's easy (my code is only 700 lines.) It runs on both
4.2BSD and System V, provided that all three ingredients are present.
This package runs about as well as you could hope for, (the buffering
and ioctl problems Henry mentions are solved using ptys, and it doesn't
eat up much CPU time, and all my windows are the full 80 cols wide)
and I have a 60 line terminal so there's really room for two or three
windows. I use this rarely, because I dont' like the "mushy" feeling I
get from the screen management layer.
(3) Berkeley job control. Henry may think this is ugly, but from a user's
point of view, if you can't have a real bitmapped display, this is the
next best thing. I strongly prefer it to (2).
(4) System V shell layers. I don't use this very often, it's just not
very powerful and awfully inconvenient. It can't pop you out from any
program that runs in raw mode, such as cu or rlogin, because there's
no way for a program to suspend itself. rlogin really NEEDS to suspend
output in a non-window environment, otherwise your screen will be a mess.
I should mention that my major use of multiplexing is to switch between
rlogins to various other systems on our LAN, and a few local applications
such as vi, mail, and news. For situations where I really need two windows
(e.g. developing a network client and server) I strongly prefer to do it
on a true window system. It is possible that others, running other mixes
of applications, will feel differently.
My recommendation is, however, similar to Henry's, for the standard.
I don't think the dumb terminal window manager is the answer, but I
think it's clear we don't have the best answer yet, in general. I do
think that certain things should be standardized:
(a) termio, or at least the subset that's commonly used. You could always
put in a few high level subroutines like the cbreak/nocbreak echo/noecho
erasechar/killchar/baudrate routines in curses, just to provide a
portable interface.
(b) an ioctl to find out the current window size, in chars and pixels.
(c) a pty-like mechanism. (Streams may be a viable candidate here, or
Illinois/Berkeley ptys might be expedient.)
(d) a software-multiplexing mechanism, like select.
Mark
Volume-Number: Volume 7, Number 40
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <5979@ut-sally.UUCP>
Date: Fri, 10-Oct-86 16:18:00 EDT
Article-I.D.: ut-sally.5979
Posted: Fri Oct 10 16:18:00 1986
Date-Received: Sat, 11-Oct-86 04:50:45 EDT
References: <5932@ut-sally.UUCP> <5965@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 40
Keywords: POSIX Appendix C
Approved: j...@sally.utexas.edu
Summary: consider the virtual console paradigm as well
From: campbell%maynard.U...@harvisr.harvard.edu (Larry Campbell)
Date: Fri, 10 Oct 86 00:52:48 EDT
Organization: The Boston Software Works, Inc.
There's another flavor of terminal I/O multiplexing that Mark Horton
didn't mention. It's widely available today; it requires no changes
to user mode code (in fact, its presence is not detectable by user
mode code); it does not require bit mapped or graphics terminals; and
I've found it to be more useful and pleasant than I would have guessed.
"It" is the "virtual console" feature found in most PC-based UNIX
implementations. This does rely on memory-mapped video, but character-
mapped terminals work as well as bit-mapped ones. Typically, four to
ten function keys are used to select four to ten virtual consoles.
Each virtual console occupies the entire physical screen; you can
only see one at a time. Keyboard input goes to the current (visible)
virtual console. Since the video is memory mapped, switching is
instantaneous.
A process trying to write to a non-current virtual console will (fill
up some clists and then) block. A process trying to read the keyboard
will block until the user switches to its console and types something.
This is all completely invisible to user programs; they think they're
dealing with a perfectly ordinary 24x80 terminal. No SIGTSTP, no window
size ioctls, etc.
I've used several "true" windowing systems before (Xerox Star, Apple
Macintosh, Microsoft Windows, Symbolics 3600) and I find I like the
virtual console paradigm far more than I would have anticipated. It's
simple and uncluttered.
I'm not suggesting that virtual consoles become part of the standard;
just pointing out a useful alternative design.
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
ARPA: campbell%maynard.u...@harvard.ARPA 120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
Volume-Number: Volume 7, Number 46
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <5990@ut-sally.UUCP>
Date: Sat, 11-Oct-86 21:27:08 EDT
Article-I.D.: ut-sally.5990
Posted: Sat Oct 11 21:27:08 1986
Date-Received: Sat, 11-Oct-86 23:58:32 EDT
References: <5986@ut-sally.UUCP> <5932@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 41
Approved: j...@sally.utexas.edu
From: g...@sun.com (Guy Harris)
Date: Sat, 11 Oct 86 02:49:48 PDT
> "It" is the "virtual console" feature found in most PC-based UNIX
> implementations. This does rely on memory-mapped video, but character-
> mapped terminals work as well as bit-mapped ones.
No, you don't need a bit-mapped display to do windowing, but I presume most
people already knew that. Convergent Technologies, for instance, has a
windowing scheme on their PT terminals. It's not even a "virtual console"
scheme; you can see parts of several windows, if you want.
This sort of windowing mechanism doesn't even necessarily require a
memory-mapped screen; it merely needs a way to redraw a window when it moves
to the front. Mark Horton's earlier message describes a window manager for
dumb terminals; it even permits more than one window on the screen.
> A process trying to write to a non-current virtual console will (fill
> up some clists and then) block. A process trying to read the keyboard
> will block until the user switches to its console and types something.
> This is all completely invisible to user programs; they think they're
> dealing with a perfectly ordinary 24x80 terminal. No SIGTSTP, no window
> size ioctls, etc.
There's nothing particularly special about all this; other window systems do
the same thing. Virtual consoles are just a special case of a window system
where all windows cover the full screen.
As for the window size "ioctl", consider this: any program that thinks it's
always dealing with a "perfectly ordinary 24x80 terminal" is going to be
quite surprised when run on an Ann Arbor Ambassador with 60 lines. Programs
should not make assumptions like that.
Given that the program will then have to query "termcap" or "terminfo" to
find the size of the screen, it's not much trouble to have the routine that
reads in the "termcap" or "terminfo" entry check what the window size
"ioctl" says and only use the value in the entry if the window size is 0x0
(i.e., not specified). That's what Sun's "termcap" code does.
Volume-Number: Volume 7, Number 50
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <5991@ut-sally.UUCP>
Date: Sat, 11-Oct-86 21:32:53 EDT
Article-I.D.: ut-sally.5991
Posted: Sat Oct 11 21:32:53 1986
Date-Received: Sat, 11-Oct-86 23:58:53 EDT
References: <5965@ut-sally.UUCP> <5932@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 56
Approved: j...@sally.utexas.edu
From: g...@sun.com (Guy Harris)
Date: Sat, 11 Oct 86 03:05:09 PDT
> (1) True windows, such as a 5620, Sun, UNIX PC, etc. Each window
> acts like a terminal. This is unquestionably the best, but it
> requires special hardware, and is an area that needs to be
> standardized.
At some point, perhaps. It's unclear whether now is the time to do so. I
don't think window systems have been around long enough that people can say
"this is how to do a window system". I don't think window systems have
settled down enough to start standardizing yet. (How many people would have
thought of using PostScript as a rendering language for a window system, and
extending it to handle input events as well and act as an extension
language, before James Gosling first talked about his work? Would people
have missed that entirely when developing a standard?)
Also, what would the standard specify? A C-language binding to routines to
manipulate the screen? A set of low-level operations to render images
within a window, a high-level user interface toolkit, something in between,
all of the above, or none of the above?
> (3) Berkeley job control. Henry may think this is ugly, but from a user's
> point of view, if you can't have a real bitmapped display, this is the
> next best thing. I strongly prefer it to (2).
For what it's worth, I will point out that even though I have access to (1),
I still use (3). I haven't analyzed my use of it enough to really say why.
Some of it may be that it takes a while to pop up a new shell window in my
environment (time to start the window process that provides the simulated
terminal and time to start up the Korn shell). Some of it may be that the
EMACS key bindings I have let me suspend EMACS but not easily fork off a new
shell. Some of it may be that it is occasionally convenient to move a job
into the background when you discover it'll take a while to complete, or
move a backgrounded job into the foreground to abort it.
> I do think that certain things should be standardized:
> (a) termio, or at least the subset that's commonly used.
The current proposal before 1003.1 does this; it fixes some botches in
"termio" as it exists (MIN and TIME are not overloaded with EOF and EOL, for
instance) and restores a couple of capabilities deleted when the System III
terminal driver first appeared.
> (b) an ioctl to find out the current window size, in chars and pixels.
The current proposal has this, but does not give the window size in pixels.
The "termio" interface is really not a good portable interface for doing
graphics, since most terminals can't do graphics. As such, it's not clear
why the window size in pixels should be provided by this interface. A
program that really cares how big the window is in pixels should probably
use the local window system primitives for this, since it has to use the
window system's rendering primitives to draw things anyway.
Volume-Number: Volume 7, Number 51
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!ucbcad!nike!lll-crg!lll-lcc!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <6001@ut-sally.UUCP>
Date: Tue, 14-Oct-86 12:12:48 EDT
Article-I.D.: ut-sally.6001
Posted: Tue Oct 14 12:12:48 1986
Date-Received: Wed, 15-Oct-86 00:53:52 EDT
References: <5965@ut-sally.UUCP> <5932@ut-sally.UUCP> <5991@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 78
Approved: j...@sally.utexas.edu
From: cbosgd!cbosgd.ATT.COM!m...@seismo.css.gov (Mark Horton)
Date: Sun, 12 Oct 86 23:50:46 edt
Organization: AT&T Medical Information Systems, Columbus
The virtual screen stuff, such as UNIX or Xenix on a PC have, should be
considered a poor cousin of a true bitmapped window capability. Aside
from losing the ability to watch two windows at once, they are essentially
the same. Both are nice, neither is an alternative for anything except
a personal computer or workstation.
By the way, another possibility has been suggested: something like System
V's shell layers, but using scrolling regions in a vt100 or similar terminal
to lock the terminal into the appropriate window. You lose the ability to
see async updates in another window, and you still need ptys and select,
but you don't need curses, and you shouldn't get the mushy feeling.
Something would have to be done about ^Z not working in raw mode, so you
could break out of an rlogin or cu or vi. One way to do this would be
something like Berkeley's TIOCSTI, so the program can detect the situation
(using a multi-char escape sequence), take itself out of raw mode, and
type the ^Z itself.
(Henry's complaint about user programs having to be modified is a minor
one, in my opinion. A program that isn't screen oriented needs no
modification. A program that is screen oriented can use curses, and
curses can catch the signal and redraw the screen as needed. The only
programs that need modification are those that have to be transparently
able to pass ^Z through, this mostly means remote login programs, and
they need this kind of capability without job control anyway.)
>From: g...@sun.com (Guy Harris)
>
>> (1) True windows, such as a 5620, Sun, UNIX PC, etc. Each window
>> acts like a terminal. This is unquestionably the best, but it
>> requires special hardware, and is an area that needs to be
>> standardized.
>
>At some point, perhaps. It's unclear whether now is the time to do so.
I did not mean to imply that it should be standardized NOW, although I
think the field is starting to generate enough examples that it would be
worthwhile for someone to start looking at it. We certainly aren't ready
to put it into P.1003 yet.
What I meant is that certain common elements should be standardized,
in particular, the ioctl to get and set the current window size.
These all look the same, but with different particulars.
>> (b) an ioctl to find out the current window size, in chars and pixels.
>
>The current proposal has this, but does not give the window size in pixels.
>The "termio" interface is really not a good portable interface for doing
>graphics, since most terminals can't do graphics. As such, it's not clear
>why the window size in pixels should be provided by this interface.
The reason I mention pixels is that many of the existing ioctls seem to
bundle the pixel numbers and char numbers into the same ioctl. Perhaps
it does make sense to separate them.
By the way, I think both "get" and "set" operations should be standardized,
and the standard should state that both ioctls must work on both sides of
the pty. (This assumes we can appropriately specify what a "pty" is.)
The "get" operation can indeed be isolated into tgetnum (termcap) and
setupterm (terminfo.) But lack of standardization means that the sources
to termcap and terminfo have to be cluttered up with umpteen different
ways to do the same thing.
The "set" operation is needed for window managers, and also so there can
be a shell command to set the window size when the system gets it wrong.
(The system gets it wrong a lot in practice, all you have to do is remote
login through a link that doesn't pass the window size, such as cu, telnet,
or 4.2's rlogin. (4.3 passes the size.)) Sometimes windows get resized,
too, so it would be useful for the cu/rlogin program to be able to send a
shell command through when this happens.)
Mark
Volume-Number: Volume 7, Number 55
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!ucbcad!nike!rutgers!caip!clyde!cuae2!ltuxa!we53!
sw013b!dj3b1!killer!ndmce!pollux!infotel!ut-ngp!ut-sally!std-unix
From: std-u...@ut-sally.UUCP@ndmce.uucp (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <324@ndmce.uucp>
Date: Fri, 17-Oct-86 17:05:39 EDT
Article-I.D.: ndmce.324
Posted: Fri Oct 17 17:05:39 1986
Date-Received: Sat, 18-Oct-86 22:02:51 EDT
References: <6001@ut-sally.UUCP> <5965@ut-sally.UUCP> <5932@ut-sally.UUCP>
<5991@ut-sally.UUCP>
Sender: n...@ndmce.uucp
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 20
Approved: j...@sally.utexas.edu
From: g...@sun.com (Guy Harris)
Date: Wed, 15 Oct 86 11:18:03 PDT
> What I meant is that certain common elements should be standardized,
> in particular, the ioctl to get and set the current window size.
> These all look the same, but with different particulars.
This isn't really just a window system issue; the current "termios" proposal
avoids referring to it as a "window" size. One could imagine features, such
as end-of-"page" pauses in the TTY driver, that would use this information
even on dumb terminals.
> By the way, I think both "get" and "set" operations should be standardized,
> and the standard should state that both ioctls must work on both sides of
> the pty. (This assumes we can appropriately specify what a "pty" is.)
The "set" operation is in the "termios" proposal; since "pty"s aren't, it
doesn't say anything about whether the operation works on both sides or not.
Volume-Number: Volume 7, Number 61
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <6176@ut-sally.UUCP>
Date: Thu, 30-Oct-86 20:25:37 EST
Article-I.D.: ut-sally.6176
Posted: Thu Oct 30 20:25:37 1986
Date-Received: Fri, 31-Oct-86 03:27:08 EST
References: <6014@ut-sally.UUCP> <6001@ut-sally.UUCP> <5965@ut-sally.UUCP>
<5932@ut-sally.UUCP> <5991@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 36
Keywords: horrible
Approved: j...@sally.utexas.edu
From: seismo!mcvax!jack
Organization: AMOEBA project, CWI, Amsterdam
Last-Band-Seen: Eton Crop, That Petrol Emotion (Paradiso, 30-09).
Opinion-Of-Them: Two good and honest guitar bands....
Date: Tue, 28 Oct 86 23:39:03 +0100
I waited for some time, thinking someone else would point this out,
but nobody did, so here goes:
*CURRENT JOB CONTROL IMPLEMENTATIONS ARE HORRIBLE. HORRIBLE!
HORRIBLE!!!!!!!!*
After reading David Lennart's (sp?) article on 4.2 job control,
SYSV shell layers, and HP-UX's hybrid I was shocked, I must admit.
Both solutions are filled with horrible tricks like closing
tty's and re-opening them and then doing funny ioctl()s and the closing
them again and then reopening then and then...
It is of course a praiseworthy feat that the folks at HP managed to
sqeeze those two horrible, inconsistent, unintellegible mechanisms
into one poor kernel, but I'm afraid the result is horrible**2.
I think that, if nobody can come up with a nice&clean subset of
job control facilities, that will allow sysV and BSD semantics to
be implemented on top of them, we should forget about standardising
anything. Standardising bad mechanisms will only hinder progress
(Did I hear someone say F77? X25?).
>From now on, you can find me in the "job control is horrible" camp.
--
Jack Jansen, j...@mcvax.UUCP
The shell is my oyster.
Volume-Number: Volume 8, Number 10