Re: [SyncEvolution] server class + fork/exec dbus-server + command line testing

On Do, 2012-04-12 at 15:59 +0200, Krzesimir Nowak wrote: Branch updated and rebased, see ccs-pohly-cmdline. And they are also incomplete, aren't they? stdout and stderr from running the command line tool are captured, but they are not checked anywhere. Nor is the return code checked. +def runSyncEvolution(argsstr, envstr): + return subprocess.Popen("env `dbus-launch` " + envstr + " sh -c 'trap \"kill $DBUS_SESSION_BUS_PID\" EXIT; syncevolution " + argsstr + "'", shell = True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) + It would be better to pass arguments as array to runSyncEvolution and subprocess.Popen(). Same for the env. That avoids quoting issues: + argsstr = "--configure --sync-property \"proxyHost = proxy\" scheduleworld addressbook" + envstr = "SYNCEVOLUTION_TEMPLATE_DIR=" + os.environ["SYNCEVOLUTION_TEMPLATE_DIR"] + " XDG_CONFIG_HOME=" + self.testdir + " HOME=" + self.testdir Regarding the environment, better refactor the code that is used for starting syncevo-dbus-server and use the same environment for both processes. Regarding the dbus-launch above, why is that necessary? test-dbus.py must be running inside a valid D-Bus session. Quite the opposite, launching another session probably prevents using the syncevo-dbus-server which was already started in the outer D-Bus session by test-dbus.py. I'll have a look. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.