Xref: utzoo comp.bugs.sys5:1160 comp.unix.wizards:18661
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.bugs.sys5,comp.unix.wizards
Subject: Re: SysVR3.2 Setpgrp behaviour
Message-ID: <1273@virtech.UUCP>
Date: 13 Oct 89 03:00:15 GMT
References: <1970@oid.UUCP>
Organization: Virtual Technologies Inc
Lines: 36

In article <1970@oid.UUCP>, root@oid.UUCP (Admin-P.L. Aeten) writes:
> Having to write a file transmission program which was to be launched after some
> tape processing was done I was confronted with what I consider to be abnormal
> behaviour of 'setpgrp'. Since the tying up of a terminal (operators terminal
> using menu interface) was unacceptable (yes background (&) was possible but
> the need to know was overwhelming...well read on.

> It seems the "setpgrp" call behaves as designed and as per documentaion. However
> if followed by a 'while' or 'for' (finite or infinite) loop it will not detach
> a process from the controlling tty. I've tried both. 

It *appears* from your post that you interpret "detach a process from the 
controlling tty" as letting the program continue running while you have 
control of the tty to perform other operations. 

The setpgrp() program only places the current program into a different
process group and disconnects the link from the process to the controlling
tty.  Disconnecting the link from the controlling tty means that signals (like
SIGHUP) generated in the tty driver will not be delivered to this process and
open(/dev/tty) will fail, since this program is no longer connected to a tty.

However, what you want to do is place your program in the background.  Yes, 
you can do that from the command line (as you noted with the &) or you can
have the program do it itself (as you final example does).  This is the only
mechanism available under UNIX to do what you want to do.

This is true for all UNIXs (that I have seen).


PS-> you should still do a setpgrp() after the fork to ensure that your 
new program does not recieve signals from the terminal.
-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+