howland@tolkien.helios.nd.edu (Robert Howland) (11/28/90)
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.