Grabbing tty (rather than console)

[Robert Howland]

I originally posted this to unix.questions 11 November.  The lack of response
has been, as they say, deafining.  So I'm going to try again, working up to
.wizards (though there doesn't seem to have been much to that newsgroup
recently), as well as to sys.sun (since the TIOCCONS ioctl call is apparently
Sun-specific).  Though it's more Unix than X, there has been traffic regarding
console programs there, so I'll try that too (I'm desparate).  I hope someone
out there can help!

A short time ago, Chuck Musciano (Harris Corp.) posted a very nice X/XView
console program, 'contool', to capture console output when running an X
session.  (It's similar to the '-C' option to 'xterm', but with various bells
and whistles, including filtering of commands and a cute console icon which
flashes when such a message comes in, allowing it to be run iconified most of
the time and save screen space.)  It sets up a pseudo-terminal which then grabs
the console with an ioctl(pseudo-slave,TIOCCONS, ) command, directing the
normal console input into the pty window.  It works very nicely when one is
running on his own workstation; unfortunately, I am not.

I am currently using an [NCD] X terminal which, in turn, runs on a cluster of
publicly-accessible workstations in our Sparc lab in the College of
Engineering.  I start the session with an initial connection to such a
machine, then immediately switch into X (making the original window
disappear).  Using 'contool' thus has two results:

   1)  Grabbing the console locks anyone else out of the machine I happen to be
       running on.  While, in a selfish way, this might not be bad, it _is_
       inconsiderate; furthermore, enough people know about how to reboot the
       machines that I am likely to be--in fact have been--interrupted in the
       middle of a session.  Very annoying.

   2)  Output sent to MY "console"--actually a tty running on the
       workstation--including error messages from X processes opened at that
       window and 'talk' requests and the like, doesn't get sent to me at all.
       This is, after all, the intent of having a console program working, and
       not getting this output pretty much defeats the purpose of the code in
       the first place.

This brings me to the question, then:  is there an easy way to connect a tty
(other than the console) to another process?  While the original program is
one-way only--it doesn't allow commands in the pty to be sent to the console,
it would seem possible to get a stream connection between the two tty's--the
original session and my X session, giving bi-directionality of communication.
Though I'm not sure, this is hardly critical, and I'd be satisfied with
mono-directional streaming.

I'm basically a [dumb] ME and have only been working with UNIX and C since
April (background in FORTRAN).  At the same time, I did go so far as to try to
go through the code to see if I could do it myself.  The ioctl( ,TIOCCONS, )
gets the console; it is common to all the "console" programs/options I
have seen.  It would seem possible that there should be some other option which
would similarly grab a tty--allow redirection of input to that already-opened
tty (from which the X session is spawned, recall) to the pty 'contool' has
established.  But ioctl has an excessive number of options (scattered all over
the man pages), and I'm not even sure if it is this or fcntl I should be
looking at.  I have looked into dup2 and even programmed it:  it doesn't grab
the console, but it doesn't do anything else, either; the problem _seems_ to be
that an 'open' to the [original, X-spawning] /dev/ttyp? doesn't return the
field descriptor of the _original_ tty--different process.  Another possibility
is to use an 'freopen'; it seems to redirect output, but there is a similar
problem getting the stream associated with the _original_ tty.  'stat' seems to
return the i-node--if this is correct from the spawned process which actually
calls 'contool'--and if I understand this correctly, that is actually what is
needed to be able to access the same file/device.  I also considered pipes, and
even brushed around the edges of sockets (scary).

At this point (probably partly due to inadequate background!), I am hopelessly
confused, as you can tell.  Obviously, my prime concern is to get the console
program to work!  At the same time, I would appreciate some minimal
understanding of what is going on, and why various other options mightn't work.
I am grateful for any help on this and thank anyone in advance for their
time/consideration.