On Mon, 07 Feb 2011 19:22:24 +0100, Steven Watanabe <watanabesj@gmail.com> wrote:
[...]* create_child: since the argument is the path to the file, why don't you take a boost::path, instead of a string?
There is no special reason - I'm fine with anything. I remember that some had argued to depend on as few Boost libraries as possible but that's not necessarily my opinion. boost::path would be fine for me.
* It seems like redirecting a stream to a file should be supported. Maybe it can be done with inherit, but it isn't immediately obvious and I'd rather not deal with handle::native_type at all.
Ok, a stream behavior to redirect to a file could be provided by default.
[...]* Why do you have to pass a native handle to pipe's constructor. Can't it be overloaded to take a handle?
boost::process::pipe is a typedef for boost::asio::posix::stream_descriptor (POSIX) or boost::asio::windows::stream_handle (Windows). As these classes belong to Boost.Asio they don't know boost::process::handle (and even request ownership of native handles).
* "On POSIX systems you must use the macros defined in sys/wait.h to interpret exit codes."
This forces me to use #ifdefs in my code. Isn't there a way to abstract this better? At least you could wrap the macros and have a trivial implementation for windows (WIFEXITED -> true)
I'm not sure whether we can abstract away what I think is a conceptual difference. No matter what we do one developer has to do something extra: The POSIX guy has to use macros and the Windows guy has to call a dummy function which always returns true before he can evaluate the exit code. While it's both not nice I find the macros less obfuscating (as it's POSIX which requires to do something extra). If there is a standard approach to handle WIFEXITED though (what is typically done if WIFEXITED returns false?) maybe we can support this?
[...]* What is the behavior of find_executable_in_path W.R.T. extensions. On windows, does it use PATHEXT? I'd like to see this spelled out explicitly.
This reminds me of an email I had received a while back. The Windows implementation of find_executable_in_path() must be changed. It's currently based on SearchPathA() but we probably have to use FindFirstFile() and FindNextFile(). Then we can also do what we like and use PATHEXT for example.
* What about file associations/#!xxx for create_child? i.e. can I run create_child("script.pl") or do I need to use shell? I can live with it either way, but the reference needs to specify it.
I should test this myself (commands are passed to "/bin/sh -c"). Thanks, Boris