Subject: Re: [boost] [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-08 19:14:59
On Mon, 07 Feb 2011 19:22:24 +0100, Steven Watanabe <watanabesj_at_[hidden]>
> [...]* 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").