On Tue, 21 Apr 2009 23:21:14 +0200, vicente.botet <vicente.botet@wanadoo.fr> wrote:
[...]I will organize the specific classes on a specific platform namespace common for the portable part
namespace process { namespace common { class process; class child; }
posix for the posix based OS
#ifdef BOOST_PLATFORM_POSIX // or something like namespace process { namespace posix { class process : public common::process{...}; class child: public common::child{...}; } } #endif
window for the micosoft OS based platforms
#ifdef BOOST_PLATFORM_WINDOWS // or something like namespace process { namespace windows { class process : public common::process{...}; class child: public common::child{...}; } } #endif
// other platforms
and have typedef or a using directive at the namespace process level for each one of the available classes as
namespace process { #if defined(__POSIX__) // or something like typedef posix::process process; // or using posix::process; #elsif defined() // other patforms ... #else typedef common::process process; or // using common::process; #endif }
When the user use a non portable feature on a portable programm it will need to check conditionally for the non portable feature as
#ifdef BOOST_PROCESS_HAS_SPECIFC_FEATURE_1 // ... #else // ... #endif
I see. Thanks for the suggestion! I don't know if this design has been considered by the original developers or if they had good reasons to reject it and go with the current design. The problems with Boost.Process really seem to be unique as too many features are platform-dependent. I don't know any other Boost library which had to face similar problems.
[...]If the command fails it can be recovered
Commands could be composed using pipe "|", shell::cat("/tmp.file.txt") | shell::wc();
redirection ">"
shell::cat("/tmp.file.txt") | shell::wc() > str;
tee
shell::cat("/tmp.file.txt") | shell::grep () | shell::tee("file");
conditional concatenation "&",
shell::cd("/tmp") & shell::ls();
which executes ls only if cd /tmp succeeds.
Another nice idea! However I'm pretty sure that I unfortunately won't be able to work on this in the near future given the amount of more fundamental problems. :-/
[...]Last some minor questions: What about renaming handle by native_handle?
I'm open to it. You want native_handle to be a first-class citizen? Then it should move out of the detail namespace, too?
What is wrong on using the Boost.Filesystem library to idientify executables?
Support for boost::filesystem::path could be added, too. However it doesn't solve the narrow/wide string problem if that's what you meant?
Why the do we need to duplicate the name of the executables as an argument?
There's no way to distinguish otherwise if the first argument is the executable name or if it's meant to be the first command line argument. Currently Boost.Process simply copies all arguments into the array which is passed as a parameter to main(int argc, char *argv[]).
Respect to relative or absolute path of executables,why not let the undelying platform to handle with this?
Then developers would need to resolve paths themselves (or use a helper function) if they want to write platform-independent code? Boris
[...]