Detecting Pipe Using Bourne Shell

Dan Bernstein bernsten at phoenix.Princeton.EDU
Sat Apr 15 11:07:41 AEST 1989


In article <910 at pkmab.se> ske at 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 at phoenix.princeton.edu



More information about the Comp.unix.wizards mailing list