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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk