job control
Moderator, John Quarterman
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
Moderator, John Quarterman
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
std-...@ut-sally.uucp
Date: Thu, 9 Oct 86 10:21:55 PDT
Organization: Peregrine Systems, Inc, Irvine Ca
>From: pyramid!utzoo!he...@sally.utexas.edu (Henry Spencer)
>Date: Sat, 4 Oct 86 03:03:30 PDT
>
> 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.
One idea would be to put Ritchie's streams in the standard or an extension
of the standard so that there is a "clean" way of writing user level window
managers. Given this there would probably be many window managers implemented
and likes shells you wouldn't need a single standard one, but could provide
several and allow users to write their own.
[ Does anyone from the /usr/group networks or windowing systems groups
have any comments on this? -mod ]
Volume-Number: Volume 7, Number 45
std-...@ut-sally.uucp
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%maynar...@harvard.ARPA 120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
Volume-Number: Volume 7, Number 46
Moderator, John Quarterman
Date: Fri, 10 Oct 86 20:38:59 CDT
The following was sent to me in private mail, with permission to publish.
He's got an interesting point.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
-----
>From: ihnp4!mecc!sewilco
Subject: Re: Window-based multiplexing
My opinion is that the multiplexing characteristic of a line should be
separated from the windowing. The multiplexing should also not be
terminal-oriented so it can be used as a multiplexed intersystem line.
I've heard several people echo my wish to be able to have file transfer
multiplexed with a terminal session, or have high-priority transfers
be interleaved with a long low-priority transfer. And with computer
ports always in short supply it would be nice to use a $600 multiplexer
to add a few more terminals and printers (several WY-50 on a table is a
poor man's windowing system).
Scot E. Wilcoxon Minn Ed Comp Corp {quest,dicome,meccts}!mecc!sewilco
45 03 N 93 08 W (612)481-3507 ihnp4!meccts!mecc!sewilco
-----
Volume-Number: Volume 7, Number 48
Moderator, John Quarterman
Date: Sat, 11 Oct 86 02:29:27 PDT
> > 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 control from the other side. Some existing systems do
> > implement such things, but the lack of standardization largely prevents
> > use of them in portable programs.
> One idea would be to put Ritchie's streams in the standard or an extension
> of the standard so that there is a "clean" way of writing user level window
> managers. Given this there would probably be many window managers
> implemented and likes shells you wouldn't need a single standard one, but
> could provide several and allow users to write their own.
Streams don't in and of themselves provide a "clean" way of writing
user-level window managers. As Henry pointed out, a pseudo-tty is what you
want here; you have a window manager that simulates a terminal (using a real
terminal or some other sort of display) and provides a tty-like interface to
clients using a pseudo-tty.
Streams might permit a fairly clean implementation of a pseudo-tty, but they
don't provide the only clean way of writing user-level window managers; any
sufficiently powerful pseudo-tty mechanism will do that. Streams might
provide the cleanest way of providing a sufficiently powerful pseudo-tty
mechanism.
Volume-Number: Volume 7, Number 49
Moderator, John Quarterman
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
Moderator, John Quarterman
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
Moderator, John Quarterman
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
Moderator, John Quarterman
Date: Sun, 12 Oct 86 22:37:40 PDT
> From: cbosgd!cbosgd.ATT.COM!ma...@seismo.css.gov (Mark Horton)
>
> ...
>
> (b) an ioctl to find out the current window size, in chars and pixels.
I've argued this with the people at Berkeley and lost, but I'll try
again here. I don't believe there should be an ioctl to find out
the pixel size of a "window". This seems to me to be the wrong way
to retrieve this information. The pixel size is of no use to programs
that deal only in characters. Only programs manipulating windows will
need to know the pixel size. Whatever mechanism is used to manipulate
window should also be used to find out the pixel size of the window.
(Of course, this may be, but is not required to be, ioctl's.) The tty
subsystem, which deals only in characters, should not know anything
about pixels or windows.
Bill Shannon
Volume-Number: Volume 7, Number 57
Moderator, John Quarterman
Date: Sun, 12 Oct 86 11:43:38 EDT
Organization: The Boston Software Works, Inc.
In article <59...@ut-sally.UUCP> g...@sun.com (Guy Harris) writes:
>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.
Of course, but I suspect that redrawing windows over a serial line
would be tedious -- unless the serial line were running at 56KB or better.
>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.
That was an oversimplification on my part. Of course programs should
(and most do) query termcap/terminfo. However, they can safely assume
that the window size isn't going to change while they're running, and
this assumption reduces complexity.
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
ARPA: campbell%maynar...@harvard.ARPA 120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
Volume-Number: Volume 7, Number 58
Moderator, John Quarterman
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
std-...@ut-sally.uucp
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Date: 15 Oct 86 12:23:31 PDT (Wed)
> From: sha...@sun.com (Bill Shannon)
> I don't believe there should be an ioctl to find out the pixel size of a
> "window". ... The pixel size is of no use to programs that deal only in
> characters. Only programs manipulating windows will need to know the pixel
> size. ... The tty subsystem, which deals only in characters, should not
> know anything about pixels or windows.
Naive programs should have access to window size as character information,
but there are programs which do not manipulate windows which need window
size information in pixels. My solution would be to provide the size in
character units but also provide character cell size in pixels with the same
call (ioctl or whatever). Programs could use it or ignore it.
Whether the tty system does know about pixels or not, it should. If the
window size information (in character units) is going to be accurate, window
sizes must be restricted to integrals of character size. With straight ttys
this is no problem, but if the system supports font changing, character size
can vary. Rather than require one call to find the window size and then
another call to find out what the units are, this information should be
consolidated into a single place.
Volume-Number: Volume 7, Number 64
std-...@ut-sally.uucp
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
In article <60...@ut-sally.UUCP> Larry Campbell
<campbell%maynar...@harvisr.harvard.edu> writes:
> Of course programs should (and most do) query termcap/terminfo. However,
> they can safely assume that the window size isn't going to change while
> they're running, and this assumption reduces complexity.
Programs cannot safely assume that window size is not going to change,
because on most overlapped window management systems it will. It is just
too easy to set inappropriate window sizes and then need to adjust them.
Consider creating a new which is almost the right size (say 75 characters
wide) and then invoking an editor on a file of 80 character data. The
editor will either wrap or truncate the data, and changing the window size
to compensate will do nothing but frustate the user. What is needed is
something like 4.3 BSD's WINCH signal, to advise those applications which
care about such changes.
--
Robert Reed, Tektronix CAE Systems Division, bo...@zeus.TEK
Volume-Number: Volume 7, Number 65
Moderator, John Quarterman
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
std-...@ut-sally.uucp
Date: Sat, 25 Oct 86 00:19:53 PDT
> From: bobr%zeus.te...@RELAY.CS.NET (Robert Reed)
> Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
> Date: 15 Oct 86 12:23:31 PDT (Wed)
>
> Naive programs should have access to window size as character information,
> but there are programs which do not manipulate windows which need window
> size information in pixels.
I'm still waiting to hear about such programs that aren't dependent on
the particular window system they are running under.
> Whether the tty system does know about pixels or not, it should. If the
> window size information (in character units) is going to be accurate, window
> sizes must be restricted to integrals of character size. With straight ttys
> this is no problem, but if the system supports font changing, character size
> can vary. Rather than require one call to find the window size and then
> another call to find out what the units are, this information should be
> consolidated into a single place.
If you want both at once, the window system can do the consolidation.
The tty driver should not know about pixels.
Bill Shannon
Volume-Number: Volume 7, Number 92
Moderator, John Quarterman
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, ja...@mcvax.UUCP
The shell is my oyster.
Volume-Number: Volume 8, Number 10
Moderator, John Quarterman
Organization: Intel Corp. Hillsboro, Oregon
Date: Wed, 08 Oct 86 14:59:16 -0800
I object to one claim made by Henry Spencer on job suspension:
>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.
Completely independent of terminal interfaces, job suspension is a
useful feature. In particular, I have a batch queue mechanism in
mind on 4.2bsd UNIX which suspends batch jobs when the interactive
load gets too high, and restarts them (sending SIGCONT) when
the interactive load drops again. This control can be done both
by an operator and by a daemon, and has no notion of controlling
terminal for the batch job.
As Henry indicates, job suspension and multi-process control are
two different items. Even though job control may not be the only
or best way to implement multi-process control, job suspension is
an important feature in its own right.
--
Jim Valerio ogcvax!inteloa!omepd!jimv, tektronix!psu-cs!omepd!jimv
Volume-Number: Volume 8, Number 15
Moderator, John Quarterman
Date: Tue, 4 Nov 86 22:47:30 est
Organization: Hadron, Inc., Fairfax, VA
In article <61...@ut-sally.UUCP> you write:
>From: seismo!mcvax!jack
>Organization: AMOEBA project, CWI, Amsterdam
>Date: Tue, 28 Oct 86 23:39:03 +0100
>
>*CURRENT JOB CONTROL IMPLEMENTATIONS ARE HORRIBLE. HORRIBLE!
>HORRIBLE!!!!!!!!*
>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.
>>From now on, you can find me in the "job control is horrible" camp.
Jack, one gets the vague feeling you dislike these implementations,
without the least notion why. Could you please meditate, or take a
pill, or whatever soothes you, and then tell us exactly why you feel
this way? (You may wish to take frequent mellow breaks.) Perhaps
you could also tell us what you feel defines a non-horrible job
control implementation. Thank you!
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
js...@hadron.COM (not yet domainised)
Volume-Number: Volume 8, Number 41