Tech Insider					     Technology and Trends


			      USENET Archives

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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/