Python’s os.system Considered Harmful

At OSAF we used Python not just for Chandler Desktop Client, but also for the tests and test frameworks. An important part of a fully automated test system is that, well, it stays automated and does not require someone to go poke at it when something gets stuck. Another important part of a test system is that you need to find out how the tests went. The way we did this was with test frameworks that launched Chandler and run unit, functional and performance tests and gathered and reported the results. Now clearly os.system was not up for the job. It rarely is in my opinion.

While os.system is great for quick hacks, its use needs to be thought carefully in production systems. Most likely you would need an external system that works around the limitations of os.system.

There are lots of problems with os.system. For example, if the command that is being called hangs, the Python code also hangs. And the caller will generally have no idea if the call actually succeeded. There is also no way to capture the output of the command that is being run, nor is it possible to change the environment for the command to be run.

Python 2.5 provides much better ways to execute external programs. There is the subprocess module, but unfortunately even that has some limitations. There is an improvement called the killableprocess module.

But even killableprocess is not enough in certain situations. Cygwin Python can not kill native Windows processes. There is a nasty hack to killableprocess to – ironically – use os.system to issue TASKKILL command. It is also tricky to capture output in all possible combinations of already redirected output, different platforms, and whether or not you want to redirect output to files and/or output it as it happens. There is a well tested sample here (check the runCommand function).

Similar Posts:

    None Found