SysVR3.2 Setpgrp behaviour
Conor P. Cahill
cpcahil at virtech.UUCP
Fri Oct 13 13:00:15 AEST 1989
In article <1970 at oid.UUCP>, root at 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 |
+-----------------------------------------------------------------------+
More information about the Comp.unix.wizards
mailing list