If you add a directory into PATH on Windows so that the directory is in quotes, subprocess does not find executables in it. They are found by the operating system, though, at least when run on the command prompt.

To reproduce:

C:\>python --version
Python 2.7.3
C:\>type test\script.bat
@echo off
echo hello
C:\>set ORIG=%PATH%
C:\>set PATH=%ORIG%;test
C:\>script.bat
hello
C:\>python -c "from subprocess import call; call('script.bat')"
hello
C:\>set PATH=%ORIG%;"test"
C:\>script.bat
hello
C:\>python -c "from subprocess import call; call('script.bat')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Python27\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified


I don't think you ever need those quotes, even if the directory would have spaces, but it is very confusing that the behavior is different on the command prompt and with subprocess. Additionally, Linux does not suffer from this problem:

$ python --version
Python 2.7.3
$ cat test/script.sh 
#!/bin/sh
echo "hello"
$ PATH=$PATH:test script.sh
hello
$ PATH=$PATH:test python -c "from subprocess import call; call('script.sh')"
hello
$ PATH=$PATH:"test" script.sh
hello
$ PATH=$PATH:"test" python -c "from subprocess import call; call('script.sh')"
hello

@Pekka sorry about the delay in getting back to you.

I can confirm that this is still in issue in 3.4.1 and 3.5.0a0.

Under the covers, subprocess is calling CreateProcess so there's really not very much we can do here, short of writing our own PATH-handling.

As a matter of fact, passing shell=True will produce the desired effect. Since the only thing this does is to run the process under cmd.exe I assume that cmd.exe itself adds some kind of PATH handling of its own.

I recommend closing as "won't fix".

Why are new versions getting added to an issue that was closed 5 years ago? 

That said, I'd like to clarify that this was not and is not a bug. It happens that the CMD shell strips quotes out, but that doesn't make it valid. PATH in Windows is delimited by semicolons, not spaces, so paths with spaces should never be quoted. In particular, WINAPI SearchPathW, which CreateProcessW calls, leaves quotes in the directory name when testing whether a file is in the directory.

Also, the conclusion that Linux doesn't suffer from this problem is incorrect. The shell command that was used actually strips the quotes out as part of command-line pre-processing, i.e. `PATH=$PATH:"test"` results in the same PATH value as `PATH=$PATH:test`. But it will fail to find "script.sh" if you escape the quotes to make the shell add them literally to PATH, e.g. `PATH=$PATH:\"test\"`.