Path: utzoo!utgpu!water!watmath!clyde!mcdchg!illusion!marcus
From: marcus@illusion.UUCP (Marcus Hall)
Newsgroups: comp.unix.wizards
Subject: Re: /dev/tty doesn't exist?
Message-ID: <169@illusion.UUCP>
Date: 7 Jan 88 02:43:58 GMT
References: <445@minya.UUCP> <2256@crash.cts.com>
Reply-To: marcus@illusion.UUCP (Marcus Hall)
Organization: Magic Numbers Software, Bloomingdale, IL
Lines: 49

In article <2256@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes:
>In article <445@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>>The first hint was from a script that did something like:
>>|	echo "This is an error message." >/dev/tty
>>so that it could write to the control terminal regardless of how output
>>had been redirected.  Instead of the error message, what appeared on the
>>control terminal was:
>>|	/dev/tty: cannot create
....
>
>What you need to do is have your main program (the one that is directly
>running from init) open the terminal in question.  You might want to call
>setpgrp() first, just to make sure you have your own process group, and to
>allow this program to work when run in other ways.  Then, you can have
>child processes (such as shell commands) that use /dev/tty.  You can also
>leave the tty open when you fork the subprocesses, allowing them to use
>the file descriptors you already have open, rather than opening the tty
>again in the child.

Well,,,,,

This is indeed the problem, but I'm afraid that this solution will not
work.  As it turns out, a tty can be the control terminal of only one
process group at a time.  (I don't have the man page here, but it reads
something like "when a process opens a tty device for the first time"
which actually means that the device is opened for the first time.)  I
have tried to figure out ways around this problem without success.  If
anyone has any suggestions, I'd really like to hear them.

If you don't do a setpgrp() call, you will still be able to access /dev/tty
because your login shell is the process group leader and it should have
a control terminal (There are ways around this, so this statement isn't
strictly true, but it usually is.)  For ksh at least, there is a flag,
-m I believe (check this to be sure) that causes it to place all backgrounded
jobs into their own process groups.  If you use ksh, clear this flag and
see if your program works, for other shells, check for a similar flag.

Incidently, the reason that a tty device can be attached to only one process
group is that there is a pointer in the tty structure that points to the
process group.  When an interrupt or kill character is processed (or other
conditions at times), this is used to send a signal to the process group.
It would have been just about as easy to just have the proc table entries
point to the control terminal and scan the proc table for pointers to the
terminal generating the signal, (the proc table has to be scanned to
distribute the signal to the process group anyway), but that's just how it
is done -- no use worrying about how it "should" have been done :-)

Marcus Hall
..!{ihnp4,mcdchg}!illusion!marcus