----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19162/#review37021 -----------------------------------------------------------
3rdparty/libprocess/include/process/subprocess.hpp <https://reviews.apache.org/r/19162/#comment68279> I thought we always named all arguments in the codebase? 3rdparty/libprocess/include/process/subprocess.hpp <https://reviews.apache.org/r/19162/#comment68277> s/string &/string& / 3rdparty/libprocess/include/process/subprocess.hpp <https://reviews.apache.org/r/19162/#comment68278> s/> &env/>& env/ 3rdparty/libprocess/src/subprocess.cpp <https://reviews.apache.org/r/19162/#comment68274> s/string &command/string& command/ and s/> &env/>& env/ 3rdparty/libprocess/src/subprocess.cpp <https://reviews.apache.org/r/19162/#comment68273> s/string /string& / 3rdparty/libprocess/src/subprocess.cpp <https://reviews.apache.org/r/19162/#comment68280> shouldn't we be escaping keys/values... setenv technically isn't async-signal-safe but that could be used in the child or, even better, we should use execle rather than execl - Ian Downes On March 12, 2014, 11:26 p.m., Dominic Hamon wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19162/ > ----------------------------------------------------------- > > (Updated March 12, 2014, 11:26 p.m.) > > > Review request for mesos, Benjamin Hindman and Ben Mahler. > > > Repository: mesos-git > > > Description > ------- > > See summary > > > Diffs > ----- > > 3rdparty/libprocess/Makefile.am 3c6219eb6e76306463b3710ab7e50ec8b75d3d76 > 3rdparty/libprocess/include/process/subprocess.hpp > d16cbc1e3d464e1784f116ccdb327cf0784f07c2 > 3rdparty/libprocess/src/subprocess.cpp PRE-CREATION > 3rdparty/libprocess/src/tests/subprocess_tests.cpp > d15d4d159105474117c4ea432b215431209ab539 > > Diff: https://reviews.apache.org/r/19162/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Dominic Hamon > >
