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: Alex Perry (Alex.Perry_at_[hidden])
Date: 2012-11-16 06:28:54

On  15 November 2012 17:39 Yakov Galka [mailto:ybungalobill_at_[hidden]] wrote :-
> 
> Alex, I'm sorry, but I cannot make sense of what you write.
>
Sorry was probably trying to be too concise and so didn't make sense.

> 
> What is foo? I assume you mean that foo is some executable. In such case it
> does not matter what it expects, 8 bit encoded command line or UTF-16
> command line, since both are passed through the kernel as UTF-16 strings.
>
If we take some hypothetical executable foo which exists in executable form on both windows and linux and also assume that it takes the same parameters in both cases (this is probably a very restricted use case already but in any other case there would be probably be #ifdef code at the calling site)

So at the command prompt / shell a call for foo (ignoring any path searching) would be something like :-

"c:\foo_directory\foo.exe -f c:\tmp\somefile.foo" on windows
"/usr/bin/foo -f /tmp/somefile.foo" on linux
(was going to add VMS here but its been too long since I used it to remember any syntax)

I was trying to point out (obviously unclearly) possible problems with the single command line version of execute

Francois had suggested the following sensible looking syntax and change to the current boost process candidate

>>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"), ...); 
>>
>>for single string, and a another option like this 
>>
>>execute(args(my_argument_sequence), ...); 
>>
>>for arguments provided as a sequence, where the executable is the 
>>first element in the list. No need to always put separate run_exe, and 
>>no need for set_cmd_line and set_args to be different. In this case, 

So using the foo as given above

execute(args("/usr/bin/foo -f /tmp/somefile.foo""));
execute(args("c:\\foo_directory\\foo.exe -f c:\\tmp\\somefile.foo"));

I guess my point was simply that this args string would differ (whether it was encoded in utf8 or not) between platforms so doesn't seem to help to provide a uniform interface. So whilst not totally against it (it does provide a very simple usage) I wasn't sure whether it helped.

Given 

boost::filesystem::path foo_path = ....
boost::filesystem::path somefile_path = ...

which have been determined by some mechanism (hopefully in a x-platform manner without #ifdefs)

std::vector<boost::filesystem::path::string_type> vArgs;

vArgs.push_back( foo_path.native() );
vArgs.push_back( "-f" );
vArgs.push_back( somefile_path.native() );

execute( args( vArgs ) );

seemed sufficient  - trying to force this into a utf8string (I may have misunderstood what you were arguing for) just seems awkward to me.

Alex