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-13 17:15:02

On Tue, Nov 13, 2012 at 2:14 PM, Boris Schaeling <boris_at_[hidden]> wrote:
> On Wed, 07 Nov 2012 23:30:25 +0100, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
> wrote:
>>
>> 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. :)
>

If we look at the variant using a vector for arguments, in that case,
seems like it is quite trivial to get the executable as the first
element in the vector. Anyways, seems to me that either you have to
merge args in a vector in a single string on Windows, or split the
string into an array of args on Unix. So if you anyway have to split,
why not make run_exe optional? Or are you using the shell on Unix?
Hopefully not (sorry, I did not download and look at the code, just
the documentation a bit).

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"), ...);

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,
args could be overloaded for a string (and/or c string) and a sequence
(templated), or even a range or pair of iterators. args could be named
something else, my point is, the command line being specified as a
string or a sequence of tokens serves the same final purpose, hence it
seems to me there is no need for a different name. Granted, this
interface requires extra work to parse the string, but like I said,
unless you make use of system() or the like on Unix, you have to do it
anyways before calling any of the exec* variants, unless I am missing
something.

-- 
François Duranleau