Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!nat.vu.nl!maart
From: maart@nat.vu.nl (Maarten Litmaath)
Newsgroups: comp.unix.programmer
Subject: Re: Detecting exec(2) failing after performing fork(2)?
Message-ID: <1991Mar7.222033.4711@nat.vu.nl>
Date: 7 Mar 91 21:20:33 GMT
References: <shj.667793966@dkuugin> <1991Mar1.205944.13198@crc.skl.dnd.ca> <1991Mar4.231540.17644@nat.vu.nl> <shj.668195000@dkuugin>
Organization: Dept. of Physics, Vrije University, Amsterdam, The Netherlands
Lines: 27

In article <shj.668195000@dkuugin>,
	shj@login.dkuug.dk (Stig Jacobsen) writes:
>[...]
>Yeah! It was something like this that I wanted, where I get no
>ugly messages splattering over the parents screen and where I get
>an error return from the spawn call and not via some signal. [...]

One thing I forgot to mention: don't forget to wait() for the child,
_even_ when the spawn() has failed!

If your UNIX variant has wait4(2), waitfor(2) or waitpid(2), you can
let spawn() itself take care of it in case the execvp() has failed.

Otherwise things must be handled by a routine that takes care of all
children, if any.

The interface might be changed to:

	int	spawn(argv, pidp)
	char	**argv
	int	*pidp;

..and spawn() would return the PID in `*pidp'.

Do _not_ use the simple wait(2) system call in spawn(), as that may
reap other children as well...  The other forms of wait() weren't
invented for nothing.