That's because you want to do an exec, which essentially transforms a running process into another process. I think people generally overestimate the complexity of fork on the part of the kernel, it's not all that bad. Create a new process slot, copy the VM configuration, set the 'copy-on-write' bit and the 'write-protect' bit on the pages in the memory image of the parent and return (twice!).
If all you want is a subprocess to do something interesting to the data you already have then fork is ideal. This is - or maybe was - a very common use case.
If you also need exec then why not first abstract out the fork, you need that any way, and do the exec in the child. It's one of the most elegant solutions to the problem I've seen.
Otherwise you get a whole bunch of functional duplication between system calls.
Already the 'exec' zoo is a good example of the kind of functional duplication you'd get. Adding 'forking' and 'non-forking' versions would not seem to improve matters much.
If all you want is a subprocess to do something interesting to the data you already have then fork is ideal. This is - or maybe was - a very common use case.
If you also need exec then why not first abstract out the fork, you need that any way, and do the exec in the child. It's one of the most elegant solutions to the problem I've seen.
Otherwise you get a whole bunch of functional duplication between system calls.
Already the 'exec' zoo is a good example of the kind of functional duplication you'd get. Adding 'forking' and 'non-forking' versions would not seem to improve matters much.