Several people at Google seem to have independently discovered that
despite all of the platform-independent goodness in subprocess.py, you
still need to be platform aware. One of my colleagues summarized it
like this:
"""
Given a straightforward command list like:
cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']
You apparently cannot pass this list to any subprocess function
(subprocess.call() or otherwise) with a set of arguments that allow it
to "just work" on both Windows and non-Windows systems.
If you call:
subprocess.call(cmd, shell=False)
Then it works on Linux, but fails on Windows because it does not
perform the Windows %PATHEXT% search that allows it to find that
"svn.exe" is the actual executable to be invoked.
If you call:
subprocess.call(cmd, shell=True)
Then it works on Windows (it finds the "svn.exe" executable), but it
fails on Linux because it *only* executes the first argument in the
list ("svn") and does not pass the remaining arguments in the list to
the "svn" invocation.
This forces you to code platform-dependent behavior in how you call
subprocess.call() when using a list. For example, you can make the
shell= argument depend on the platform you're running on, like:
subprocess.call(cmd, shell=(sys.platform=='win32'))
Or you could vary cmd[0] in your list based on the platform:
if sys.platform == 'win32':
svn = 'svn.exe'
else:
svn = 'svn'
cmd = [svn, 'ls', 'http://rietveld.googlecode.com/svn/trunk']
But either way, this seems clearly broken (or at least sub-optimal)
for a module that's supposed to abstract platform-specific execution
issues from the user.
"""
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4