Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!bernsten
From: bernsten@phoenix.Princeton.EDU (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: Detecting Pipe Using Bourne Shell
Message-ID: <7754@phoenix.Princeton.EDU>
Date: 15 Apr 89 01:07:41 GMT
References: <18992@adm.BRL.MIL> <999@philmds.UUCP> <457@cbnewsc.ATT.COM> <910@pkmab.se>
Reply-To: bernsten@phoenix.Princeton.EDU (Dan Bernstein)
Distribution: usa
Organization: Hmph.
Lines: 41

In article <910@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes:
> 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've written a program ``pty'', at version 1.2 or so, that suffices for my
needs; I can do stuff like, e.g.,

  tr a b | pty /usr/ucb/vi | tee out

and get sensible results. pty runs under BSD and uses pseudo-terminals;
you can imitate script with ``pty $SHELL'', or use it far more flexibly.
I'll post it soon, when I'm happy with the option set.

> 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.

System V streams are more general than what you propose and can imitate
your e-pipes quite nicely. ptys are less general but satisfactorily
allow programs to use ioctl() as usual, even in the middle of a pipe.
If BSD goes past ptys, it should go all the way to streams.

> 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.

Oh, c'mon. I can do that without trouble, today and yesterday and many
days before that. And I believe you're overoptimistic in saying that
e-pipes would not need kernel drivers; they'd certainly need quite a
bunch of other extensions to the kernel as you describe them.

> What do you say? I want pipes usable with modern, interactive, screen
> oriented, modular programs, in addition to the usual old text processing.

I'll make sure to email you pty.c before I post it.

---Dan Bernstein, bernsten@phoenix.princeton.edu