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: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-11-16 08:13:49

On Nov 16, 2012, at 6:28 AM, Alex Perry <Alex.Perry_at_[hidden]> wrote:

> On  15 November 2012 17:39 Yakov Galka [mailto:ybungalobill_at_[hidden]] wrote :
>> 
> 
>> 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.

Your argument applies to pathnames alone. Any other arguments to a cross-platform application are unlikely to differ.

> 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 ) );

That's an inappropriate use of path. It is for filesystem paths, not arbitrary strings  Something else is necessary.

___
Rob