Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!mcnc!gatech!mcdchg!heiby
From: heiby@mcdchg.UUCP
Newsgroups: news.software.b
Subject: Re: Problem with News 2.11.6 and fix
Message-ID: <286@mcdchg.UUCP>
Date: Fri, 27-Mar-87 10:25:11 EST
Article-I.D.: mcdchg.286
Posted: Fri Mar 27 10:25:11 1987
Date-Received: Sat, 28-Mar-87 15:23:17 EST
References: <199@ems.UUCP>
Reply-To: heiby@mcdchg.UUCP (Ron Heiby)
Organization: Motorola Microcomputer, Schaumburg, IL
Lines: 29
Summary: This is not a bug.

In article <199@ems.UUCP> mark@ems.UUCP (Mark H. Colburn) writes:
>I then ran rnews -U to unspool the files 
>immediately and got the following error:
>
>	inews: rnews failed, status 256.  Batch saved in <filename>.

Mark then shows a segment of code that he says shows the parent waiting for
the child process to exit and that the child always exits with exit code 1.

>				execl(RNEWS, "rnews", "-S", "-p", dir->d_name,
>					(char *) NULL);
>				_exit(1);
>		
>This means that the child will _ALWAYS_ exit with a code of 1, and the 
>parent will _ALWAYS_ abort with an error of 256.  Obviously the fix is to 
>modify the _exit(1) to an _exit(0).

This is where Mark's wrong.  That "_exit(1);" will be executed ONLY if the
previous line, an execl(), fails.  If the execl succeeds, then the current
program isn't executing any more and it will *never reach* the exit in
the following line.  Since it is reaching that line, it means that the
execl() itself is failing.  This is probably because it can't find "rnews".
Maybe it's in the wrong directory or has the wrong permissions.  Changing
the line to _exit(0) means that we end up assuming that the rnews -S
worked just fine, and we dump the batch.
-- 
Ron Heiby, heiby@mcdchg.UUCP	Moderator: mod.newprod & mod.os.unix
Motorola Microcomputer Division (MCD), Schaumburg, IL
"There are only two of them that I think are idiots." Brian Reid