Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!bionet!csd4.milw.wisc.edu!dogie.macc.wisc.edu!indri!nic.MR.NET!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: Detecting Pipe Using Bourne Shell
Message-ID: <13589@ncoast.ORG>
Date: 21 Apr 89 00:56:57 GMT
References: <18992@adm.BRL.MIL> <999@philmds.UUCP> <457@cbnewsc.ATT.COM> <910@pkmab.se>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 48

As quoted from <910@pkmab.se> by ske@pkmab.se (Kristoffer Eriksson):
+---------------
| 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
| 
| 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.
+---------------

If AT&T hadn't introduced the I_STR silliness into Streams and instead had
elected to pass otherwise-unrecognized ioctls along the Stream, you could do
this with a Stream.  I expect that this will be in V.4 and *is* in SunOS4;
building a tty driver with I_STR isn't exactly the way to be compatible, so
I think it's safe to assume that Streams now passes random ioctls().  Given
that, a raw Stream should be able to send and receive ioctls with the
standard Streams message calls (I hope! -- I can imagine the Stream head
refusing to accept unknown IOCTL packets, but there should be a way to
request that they be passed through).

With the ability to pass ioctls through a Stream, Streams-based networks can
be designed to do local terminal handling as you suggested, and you can
write a version of script(1) which doesn't need to have an intelligent
pty-style device in the loop (I assume that causes some kernel overhead); it
can just dump the ioctls of the child to its stdin.  Seems more efficient to
me.

Of course, all this assumes that AT&T/Sun decides to do something rational.
The jury's still out on that one; I won't believe that they did it until I, or
someone I trust on the subject (say, Chris Torek or Doug Gwyn), actually
try it on a V.4 system.


++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser