Re: [boost] [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

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]>  
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