Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!kth!sunic!kullmar!pkmab!ske
From: ske@pkmab.se (Kristoffer Eriksson)
Newsgroups: comp.unix.wizards
Subject: Re: Detecting Pipe Using Bourne Shell
Summary: Better pipes
Message-ID: <910@pkmab.se>
Date: 13 Apr 89 23:11:38 GMT
References: <18992@adm.BRL.MIL> <999@philmds.UUCP> <457@cbnewsc.ATT.COM>
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
Lines: 56

In article <457@cbnewsc.ATT.COM>, nichols@cbnewsc.ATT.COM (robert.k.nichols) writes:
> In article <999@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
> Programs and procedures that use this means of distinguishing their
> input source are one of my pet peeves.  Sometimes I want to interpose an
> editing filter between my terminal and stdin of some program, giving me
> the ability to repeat previous input lines (perhaps with modifications),
> include the contents of an existing file in the input stream, etc.  Any
> program that uses "test -t 0" (or an equivalent) will break in such an
> environment.

I would like too see this problem with piping into (out of) programs that
want to use ioctl calls on its input (output) permanently cured some day.

I think the cure would be to make it possible for ioctl:s to be transferred
throu the pipe (or actually more likely, throu some parallell but unbuffered
mechanism), and read by the process at the other end of the pipe with a new
system call that could be named ioctlread(). That process then could emulate
the requested ioctl or pass it on to some other file or pipe. This would be
perfectly suited for editing filters, windowing systems, networked terminal
sessions, and more, without using ptys or System V stream modules.

Ptys are not equivelent to these extended pipes (let's call them "e-pipes").
With e-pipes, all ioctls can be passed throu the filter process or processes
all the way to the actual devices they filter, thus not limiting them to
handle tty style devices only, with only the ioctls implemented by the pty
driver (better generality). You also could have tty modes on remotely logged
in terminals in a network, propagate (with some suitable protocol) from the
remote host to the terminals local host's tty driver (or editing filter),
to do all input processing near the terminal (increased efficiency), all
without any special kernel drivers.

To further increase the usefulness of e-pipes, eliminating the need for
filter programs to know anything about e-pipes, there could be a default
"by-pass" setup where ioctls coming in on stdin automatically were passed
on to stdout, and vice versa, until the process explicitly requests to
receive the ioctls itself. This would only involve checking and optionally
following a "by-pass pointer" in the kernel, when sending ioctls. Maybe
the shell that started the pipe could arrange the by-pass according to how
the pipe was specified, using a new bypass() or shunt() system call.

With this facility it would be possible to e.g. use good old tr in a
pipe between your terminal and any other program, like editors, mail
readers, pagers, anything, without trouble. Today you can't.

I don't know enough to compare e-pipes to stream modules, but from what I've
seen on the net, they seem to be designed mostly for use from within the
kernel, and complicated to set up for use with user processes. Maybe the
shell could be made to set up streams similar to e-pipes, but I think there
would be problems/limitations.

What do you say? I want pipes usable with modern, interactive, screen
oriented, modular programs, in addition to the usual old text processing.
-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske