Am 30.10.2016 um 16:48 schrieb John Bytheway:
On 2016-10-28 09:04, Klemens Morgenstern wrote: <snip>
It's not working at all with path, it depends on the OS. The cmd-style searches path, while he exe-args style does not. That's the weird platform dependent behaviour, I'm not elaborating on enough. Boost.Process does not search the path automatically, it just uses the defaults of the OS. If you want to search the path, you have the search_path function for that, i.e. turn the first line into
boost::filesystem::path p = bp::search_path("python.exe"); So you are suggesting searching the path for the executable and then running it as a separate step? That sounds like it would introduce a race condition (if the executable is moved between being found and run) which could cause execution to fail where it would otherwise succeed (assuming there is another program with the same name later on the path).
That makes me uncomfortable. At the least, that warrants a warning in the docs, and I feel it ought to not be the recommended approach.
But maybe I'm misunderstanding; I haven't actually looked at your docs yet.
John You mean it's a race condition, because the OS would block moving of the file before launching? I guess that could happen, but that's true for all such operations, e.g. if during launch of foo.exe you move it's needed bar.dll. Or if you use boost::filesystem:
if (fs::exists(my_path)) fs::istream is(my_path); So yes if you write bp::system(bp::search_path("foo.exe")); you'd have a few cycles in between to move the file. However, I don't think that's the problem: you either have a command line, in which case the OS takes care of that or you have an absolute path. The search_path function helps you to obtain the latter, but does not lock it. I guess you could open a handle to the file to do that, but that would be very strange default behaviour.