On Tue, Nov 13, 2012 at 2:14 PM, Boris Schaeling <boris@highscore.de> wrote:
On Wed, 07 Nov 2012 23:30:25 +0100, Klaim - Joël Lamotte <mjklaim@gmail.com> 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