Message-ID: 
Newsgroups: net.unix-wizards
Path: utzoo!decvax!harpo!ihnp4!ihnet!tjr
X-Path: utzoo!decvax!harpo!ihnp4!ihnet!tjr
From: ihnet!tjr
Date: Wed Dec 15 05:59:53 1982
Subject: UNIX wish-list
Posted: Tue Dec 14 12:23:53 1982
Received: Wed Dec 15 05:59:53 1982

to: unix-wizards

Here is my wish-list for UNIX:

1) How about device-independent I/O?

Before you flame back saying "UNIX has device-independent I/O", please
note that UNIX comes close, but no cigar. Pipes are very much different
from terminals (flushing, EOFs), and files are not quite the same, either.
Most of these differences come from physical constraints, but I think things
could be better.

Consider: we have a talking-terminal for a blind co-worker, and would like
to augment its features with a UNIX process to handle the terminal I/O. This
process would be exec-ed by .profile, would setup 2 pipes and fork a shell,
setting the shell's stdin and stdout/err to be the pipes. It would monitor
the 2 streams (keyboard->pipe1->shell-stdin, shell-stdout/err->pipe2->display)
and do the appropriate modifications to its processing or to the streams.
The trouble is that the shell cannot ever receive an EOF (nor can its children),
so any command expecting to terminate on an EOF on stdin cannot be used.
Closing the pipe will "send" an "EOF" to the shell (AND any children), which
will shutdown the whole shebang; efforts to use SIGCLD to detect this and
re-fork a shell have failed (environment would be lost, anyway).


2) How about a signal indicating "you have some I/O ready" ?

In the above terminal-handling process, it is impossible to wait on
"char ready from either the keyboard or the shell-output-pipe". You could
read them both in NDELAY mode, and then sleep(1) if nothing was ready, but
that is ugly. In practice, we use TWO processes, one handling each stream,
and communicate the commands from the input-process to the output-process
via signals (a very limited command-set!).


3) Why are vi, etc. so picky about their output?

Many programs refuse to run unless they are directly connected to the tty.
Why can't they assume that the user is more intelligent than the computer,
and permit non-standard uses (when debugging a terminal, I might want to
"tee" vi's output in order to later look at what was actually sent).
Our blind co-worker is not very concerned about the lack of vi, but it's
the principle of the thing...


			Tom Roberts
			..ihnp4!ihnet!tjr
			(312) 979-6599

Message-ID: <bnews.rocheste.318>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!harpo!seismo!rocheste!avie
X-Path: utzoo!decvax!harpo!seismo!rocheste!avie
From: rocheste!avie
Date: Wed Dec 15 20:06:44 1982
Subject: Re: UNIX wish-list
References: <bnews.ihnet.106>
Posted: Tue Dec 14 22:56:01 1982
Received: Wed Dec 15 20:06:44 1982

In reference to having a signal "when terminal input is available,"
this can be done.  The signal is (I believe) SIGTINT.  An appropriate
ioctl call is also in order.  The main restriction for this is that
the user must be using the "new" tty driver.

Although this can be done, I feel it is insufficient.  The main problem
is that signals (at least UN*X signals) are lousy to begin with.  For
example, repeated signals are lost if the signal is not reset quickly
enough.  Another problem is that a signal will cause a premature return
of a system call (except for file I/O)!

I guess if I were to create a UN*X wish list, it would definitely include
improved signals.

	Avadis Tevanian, Jr.
	seismo!rochester!avie