Child processes started with boost::process have incorrect argv if executable path contains spaces

[Jonathan Jaloszynski <Jon_Jaloszynski@…>]

If an executable to start has spaces in its path, the process started with either boost::process::child or boost::process::system will have a strange argv. Specifically, the segments of the executable's path will be individual elements in the argv array.

To demonstrate this problem, the following program dumps argv:

#include <iostream>
int main(int argc, char* argv[])
{
	// Dump the command line arguments.
	std::cout << argc << std::endl;
	for (int i = 0; i < argc; ++i)
		std::cout << argv[i] << std::endl;
	return 0;
}

Compile this and place the resulting DumpCmdLine.exe in "c:\dir with space\" and "c:\dirwithoutspace\".

The following program runs this executable using boost::process, and demonstrates the problem:

#include "stdafx.h"
#include <boost/process.hpp>
#include <boost/filesystem.hpp>

int main()
{
	boost::filesystem::path	toRun{ "c:\\dir with space\\DumpCmdLine.exe" };
	auto child = boost::process::child(toRun, L"realArgument");
	child.wait();
    return 0;
}

The child process argv contains 4 elements, "c:\dir", "with", "space\DumpCmdLine.exe", and "realArgument".

When there is no space in the executable path, the child process argv contains 2 elements: "c:\dirwithoutspace\DumpCmdLine.exe", and "realArgument".

When DumpCmdLine.exe is called from the command line, it receives the same 2 arguments. The command line I used is:

"c:\dir with space\DumpCmdLine.exe" realArgument

This was observed on a Windows 10 system, 64 bit build both debug and release configurations. Visual Studio 2017 (15.4.3) was used to build.

[Jonathan Jaloszynski <Jon_Jaloszynski@…>]

When using the "command style" of execution with a quoted executable path, the expected (2 argument) argv is received by the child process. This is a bit of a hack since quoting the path is likely OS specific.

int main()
{
	std::wstring cmdString = L"\"c:\\dir with space\\DumpCmdLine.exe\" realArgument";
	auto child = boost::process::child(boost::process::cmd = cmdString);
	child.wait();
	return 0;
}

[anonymous]

Confirm this happens in my setup as well, Windows 10 x64, VS 2017, boost 1.65.1