[boost] [boost.process] 0.6 Alpha

Subject: [boost] [boost.process] 0.6 Alpha
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-06-04 15:52:00

Hi all,

the boost.process 0.6 library is now in alpha, that is: it has some 
(compiling) examples, a documentation and tests that pass on windows as 
well as on linux.

It basically allows you to manage a process like this:

pstream pipe;

child c("some_prog", "--some-arg", env["PATH"]+="C:/stuff", std_in < 
"data.csv", std_out > pipe, std_err > null, start_dir="./bin");

std::string data;
pipe >> data;

c.wait();
cout << c.exit_code() << endl;

You can find the documentation here: 
http://klemens-morgenstern.github.io/process/
Get the source code from here: 
https://github.com/klemens-morgenstern/boost-process

If you want to use it on windows, you currently would need to clone my 
boost.winapi fork also: https://github.com/klemens-morgenstern/winapi

As for the scope of the library, it is meant to implement a small, 
portable layer to allow platform-independent process management. Thereby 
it's functionality is (unless I missed something) basically what is 
possible on posix as well as on windows. There are some platform 
extension, but I would not recommend to use them. It is also possible 
(though not yet documented) to write extensions, and if they work on 
both platforms I will gladly add them.

It is however not the goal of the library, to be the be-all and end-all 
of process management; in past disscussions, different ideas where 
brought up, like implementing a DSEL for that or only allowing 
asynchronous communication. This library will never be that, since it 
would be much more fitting to build this on-top of it. E.g. a DSEL could 
be written (e.g. boost.shell) using boost.process underneath, so the 
library could concentrate only on the DSEL.

It doesn't depend on boost.iostreams anymore, though it still uses 
boost.asio, boost.fusion and boost.filesystem.

As for the open issues: some error handling is still lacking (but that'd 
be something like being unable to duplicate a handle), which would be 
required for proper extension, which is also why it's not documented.
Also there's still an open discussion about the naming of the class and 
functions (child, system, spawn), so that may change also. But I 
consider this simple enough for a easy refactoring. If anyone has naming 
ideas, please tell me. One Idea was 'subprocess' but 
'process::subprocess' just looks too strange to me.

I hope you try it out, and give me some feedbacks. Or write angry error 
reports, both helps.

Thanks!

Klemens