Xref: utzoo comp.unix.wizards:18652 comp.bugs.sys5:1159
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!cfctech!teemc!ka3ovk!ki4pv!cdin-1!dsinc!oid!root
From: root@oid.UUCP (Admin-P.L. Aeten)
Newsgroups: comp.unix.wizards,comp.bugs.sys5
Subject: SysVR3.2 Setpgrp behaviour
Message-ID: <1970@oid.UUCP>
Date: 10 Oct 89 21:18:13 GMT
Followup-To: comp.bugs.sys5 || comp.unix.wizards || poster
Organization: VU/TEXT Information Services, Phila, Pa.
Lines: 99

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. Following are two somewhat
degenerate code fragments.

	char *progname;

	main(argc, argv)
	char *argv;
	int argc;
	{
		.
		.
		.
		if( setpgrp() == FAIL )
		{
		   perror("Detach failed: ", progname);
		   exit(2);
		}

		for( cnt = 0; cnt < 2; cnt++)
		{
		   do something
		}

		.
		.
	exit(some val);
	}

The above will tie up the terminal invoked from as does the following:

	char *progname;

	main(argc, argv)
	char *argv;
	int argc;
	{
		.
		.
		.
		if( setpgrp() == FAIL )
		{
		   perror("Detach failed: ", progname);
		   exit(2);
		}

		while(somecondition)
		{
		   do something
		}

		.
		.
	exit(some val);
	}

In order to free up the terminal on the 'setpgrp' I had to arrange the
demise of the parent prior to the call.

		.
		.
		.
		.
		.

		if( pid = fork())
		{
		    if( pid == -1)
			{
			  perror("Can't fork process: ", progname);
		 	  exit(2);
			}
		    exit(0);
		}

		umask(022);

		setpgrp();
		.
		.
		.
		
[Additional information: I closed all filedes associated with the terminal
but to no avail... SysVR2.1.2 with V3.1 compiler exhibits the same condition]

I am at a complete loss to explain this. Being a curious sort I can't let
this one get by. Can anyone shed some light on why this occurs? Is the
compiler (AT&T CPLU 4.2) at fault or is this not a defect? Or am I doing
something wrong?

Thank you all!
Peter


P. L. Aeten
Manager - UNIX Production Systems
VU/TEXT Information Services

{attmail,dsinc,netsys,lll-winken}oid!paeten
Bus [215-574-4477] or Home [215-461-5540]