From: utzoo!decvax!harpo!ihnp4!ihnet!tjr
Newsgroups: net.unix-wizards
Title: UNIX wish-list
Article-I.D.: ihnet.106
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