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: Francois Duranleau (xiao.bai.xiong_at_[hidden])
Date: 2012-11-14 08:34:56

On Wed, Nov 14, 2012 at 8:24 AM, Alex Perry <Alex.Perry_at_[hidden]> wrote:
> On  13 November 2012 22:15 Francois Duranleau [mailto:xiao.bai.xiong_at_[hidden]] wrote :-
>
>>
>>[...] Have looked at Python's subprocess module? It has, IMO, a very nice
>> interface for launching processes, and you essentially specify the
>> command either as a single string or a sequence of arguments, where
>> the executable is the first element, and, following your interface, we
>> could simply end up with something like, e.g.
>>
>> execute(args("test --foo /bar"), ...);
>>
>
> Just a caveat about the python subprocess module - possibly this is fixed in python 3.0 but certainly for the python 2.X there is a problem with the python interface when used on windows. Consider:
>
> "foo my_file"
>
> Even if in the python code this is in Unicode when the process is called this is translated into 8 bit binary using the system code page which can destroy the my_file name.  There appears to be no way to get python (at least 2.x versions) to call the underlying Win32 CreateProcess  call using windows native utf16 encoding.  The only solution to this that I know of is if you are in control of foo so can arrange that it can support utf8 by an optional command line switch and do :
>
> "foo --use_utf8 my_file"
>
> Or some such.
>
> If boost process was to model python subprocess then it would need some mechanism to be explicit about what encoding should be used to actually make the call for the process and how to translate the command line correctly.

Isn't this more an implementation issue rather than an API issue?  I
mean, the underlying implementation could easily convert an input UTF8
string to UTF16 string before making the call to CreateProcess?
Granted, though, the command line string version should probably also
support wide char strings.

-- 
François Duranleau