Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!inuxc!att!ihnp4!chinet!les
From: les@chinet.UUCP (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: how can I determine controlling tty if no file descriptor is open onto it?  (System V r[23])
Message-ID: <5578@chinet.UUCP>
Date: 13 May 88 03:29:54 GMT
References: <2658@ttrdc.UUCP> <2661@ttrdc.UUCP>
Reply-To: les@chinet.UUCP (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 28

In article <2661@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>I am trying to write a program UNDER SYSTEM V RELEASE 2 AND 3 which
>disassociates itself from the controlling terminal (using setpgrp() after
>redirecting all file descriptors still open onto the terminal, into a file),
>tries to exec() a machine binary or shell script, and if that doesn't work
>sends an error message to the terminal and exits.
>...
>However, I am having a problem with always getting an error message back to
>the terminal from which the command was issued.  It does no good to try to

If ttyname() doesn't work on file descriptor 0,1, or 2, you can:
 a) forget the error message
 b) send the error message by mail to the appropriate user found by
    the environment variable LOGNAME (it's good enough for /bin/mail) or
    looking for the uid in /etc/passwd.
 c) check all the reasons that the exec might fail before closing 
    stderr.
 d) fork before closing stderr and let the parent wait a "reasonable"
    amount of time for a signal from the child indicating that the
    exec failed.

I'd go for (a) myself. If the error message isn't going to appear on
the terminal, you might as well find it where you expected the output
from the exec'ed program.
A reasonable facsimile of (b) is available from the at command, if you are in
the at.allow file.

  Les Mikesell