Detecting Pipe Using Bourne Shell

[Brandon S. Allbery]

As quoted from <910 at pkmab.se> by ske at pkmab.se (Kristoffer Eriksson):
+---------------
| In article <457 at cbnewsc.ATT.COM>, nichols at cbnewsc.ATT.COM (robert.k.nichols) writes:
| > In article <999 at philmds.UUCP> leo at 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 at ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at 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