Guido quotes a colleague:
> """
> 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.
I can't reproduce this as described.
>>> subprocess.call(['svn', 'ls'], shell=False)
svn: '.' is not a working copy
1
The reason this works is that Windows itself (CreateProcess) has support
both for implied '.exe' extensions and searching $PATH. Thus, PATHEXT
handling isn't required for executables.
I *can* reproduce with another extension - eg, 'svn.py' - for this test I
had a 'foo.py' on my PATH (but not in the cwd), and .py in PATHEXT.
>>> import subprocess
>>> subprocess.call(['foo'], shell=False)
... fails
>>> subprocess.call(['foo'], shell=True)
Hello
0
So I can't see this problem for 'svn.exe' and at face value the behaviour on
Windows looks quite correct - you *do* need the shell for this functionality
on Windows (in the same way you would to execute a .bat file, for example)
> 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.
It sounds like in this particular example at least, this behaviour on Linux
is the problem?
Mark
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
