Firing up a process and not wait()ing on it..

[Blair P. Houghton]

In article <1989Dec19.191032.21857 at lavaca.uh.edu> jet at lavaca.uh.edu (J. Eric Townsend) writes:
>
>Maybe there's an obvious answer to this that I didn't hit while
>RTFM'ing.

It's not obvious.  It's a bit of idiomatic wizardry that
you would have found in any Unix-programming-in-C book,
though.

>While in process foo, I want to crank up process bar
>and have it run independently of foo.  system("bar &") doesn't do
>the trick, as a wait() is still called for the parent shell of bar (it
>seems that's what happening, at least).

	/* fork a nother process. */

	if ( !fork() )
	    exec("bar",...);

Read the manual pages for fork(), and use the correct
exec-function (there are a slew of them that will work
under ultrix:  execl, execv, execle, execlp, execvp, exect,
and execve) to get this to work.

The basic thing is that fork() makes an exact, running copy
of the process you are running.  It returns to the original
process the pid of the new process, and "returns" to the
new process a 0.  So, now there are two programs running
separately on the system, with only their pid's, ppid's,
and the return value from this fork() to distinguish them.
They are totally independent, unless you use the returned
pid of the child explicitly in a wait-call (there's a pile
of those, too: wait, wait3, and waitpid).

The trick is to take the new process and immediately change
it, using one of the exec family, which clears out the
running process and fires up the process in the file named
in the argument to the exec call.

You'd think something as common as this (and it's in about
every program ever written that gets put into a unix
release) would become a system call of its own.  I guess the
number and variety of the exec's keeps that from happening.

Last hint:  execv("bar",(char *)NULL) is your best bet, but
look over the others to make sure you're using the features
of these functions correctly.

Absolute final hint:  There is no function that is
named exec(), and I have not the slightest idea why...

				--Blair
				  "Down and dirty systems programming."