Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!srcsip!nic.MR.NET!thor.acc.stolaf.edu!mike
From: mike@thor.acc.stolaf.edu (Mike Haertel)
Newsgroups: comp.unix.wizards
Subject: Re: Detecting Pipe Using Bourne Shell
Message-ID: <1850@thor.acc.stolaf.edu>
Date: 15 Apr 89 16:21:10 GMT
References: <18992@adm.BRL.MIL> <999@philmds.UUCP> <457@cbnewsc.ATT.COM> <910@pkmab.se>
Reply-To: mike@stolaf.edu
Organization: St. Olaf College, Northfield, MN
Lines: 67

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

This has already been done, in ninth edition streams.  A ninth edition pipe
is a bidirectional stream; a module can be pushed into it that will turn
ioctl requests (and other control messages) into formatted data blocks,
and vice versa.

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

All of this is already done in ninth edition, with streams.  Let's hope that
Berkeley gets these ideas into 4.4BSD . . .

> [ . . . stuff deleted . . . ]
>
>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.

Setting up a slave process with (v9) streams is no more difficult than
setting up a slave process with traditional Berkeley ptys.  There is
no reason that you couldn't invent a shell syntax to do this sort of
thing, except this is a very specialized and rarely used thing to deserve
special shell syntax.

	pipe(fds);
	ioctl(fds[0], PUSH, mesg_ld);
	if (fork()) {
		close(fds[1]);
		do_fancy_processing_on(fds[0]);
	} else {
		close(fds[0]);
		dup2(fds[1], 0);
		dup2(fds[1], 1);
		dup2(fds[1], 2);
		close(fds[1]);
		execl("something_to_be_run_with_controlled_standard_fds",
		      "hello, world", 0);
		_exit(1);
	}

Disclaimer: I don't have a v9 system to try this on.  Unfortunately.
Real v9 people should feel free to rip me apart on details.

Oh well, maybe we can get this into GNU.
-- 
Mike Haertel <mike@stolaf.edu>
In Hell they run VMS.