Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-15 12:59:11

Le 13/11/12 20:14, Boris Schaeling a écrit :
> On Wed, 07 Nov 2012 23:30:25 +0100, Klaim - Joël Lamotte 
> <mjklaim_at_[hidden]> wrote:
>
>> Quick questions after having read the doc:
>>  1. Does error handling works with processes we launch and don't wait 
>> for
>> too? I assume yes.
>
> Yes.
>
>>  2. I remember pointing before that in this example:
>>
>> execute(
>>     run_exe("test.exe"),
>>     set_cmd_line("test --foo /bar"));
>>
>>
>> There is repetition of the executable name. I suggested allowing to
>> set_cmd_line() without run_exe(). Did you implement this possibility?
>
> No. But I agree with you that it would be nice to have. I had to draw 
> a line somewhere though if we ever want to get a process management 
> library into Boost. (But drop me a mail if you like to contribute a 
> function which can parse the executable name and ideally considers 
> quotes, blanks and escape characters. :)
>
>> 3."On Windows a relative path is relative to the work directory of the
>> parent process. On POSIX a relative path is relative to the work 
>> directory
>> set with start_in_dir as the directory is changed before the program
>> starts."
>> Does this means that using start_in_dir on Windows have no effect?
>
> start_in_dir() works on all platforms. It's just that on POSIX this 
> happens:
>
> chdir("bla");
> execve("../foo", ...);
>
> If the path to the executable is a relative one, it's relative to the 
> new work directory as the directory is changed before execve() is called.
>
> Does the hint in the docs make sense now? Or I should rewrite it to 
> make it clearer?
>
I guess that in this case the library should either allow only absolute 
paths or transform the relative path on an absolute path so that it is 
not subject to interpretations that depend on the platform.
Could this be possible?

Best,
Vicente