subprocess interface improvements

[Andreas Rottmann]

It would be nice if the subprocess interface could be extended to cover these cases:

1) Allow choosing not to search $PATH (i.e. use execv() instead of exevp()).
2) Allow specifying the environment for the subprocess.
3) Allow using existing file handles as std{in,out,err} for the subprocess, to allow building pipelines. This would
    probably involve providing a way (internally) to get at the file descriptor underlying a specific port.

--Rotty

[Andreas Rottmann (rotty)]

I've hacked up a quick patch that does (1) and (3) -- it turned out the filehandles are readily available, so this was rather straightforward. I'm not sure about what API should be exposed to the user; the `process*' procedure I added takes quite a lot of arguments; any ideas how to enhance the API?

If my patch aims into the right direction, I'll refine it (e.g. add (2)), and when an API is settled upon, I could also write docs, if wanted.

[Andreas Rottmann (rotty)]

I've attached a new version of the patch which also covers environment passing and adds an implementation of the `execve()' function, which is not in POSIX (and also missing from glibc), allowing to search the current $PATH, while at the same time specifying a new environment for the created process.

[Andreas Rottmann (rotty)]

I've rebased the patch (onto bzr r1806) and fixed it, so that it works with the port internal representation changes in bzr r1803.

[Abdulaziz Ghuloum (aghuloum)]

Fixed in 1853.