Windows - running .py directly vs running python blah.py behaves differently

Question

I have a python script that uses subprocess:

import subprocess
print "Running stuff"
subprocess.check_call(["do_stuff.bat"])
print "Stuff run"

If this was named blah.py, and I run (from a command prompt):

python blah.py

I will get the output from do_stuff.bat (or whatever I run).

If this is run as:

blah.py

Then I do not get output from do_stuff.bat, only the print statements.

So far seen on windows Server 2003. Python version 2.5.2 (stuck there for various reasons). Looking at the associated file type action I see:

Python.File="C:\Python25\python.exe" "%1" %*

So can anyone explain the difference?

Hyacinthus

I would hazard a guess and say that explicitly calling python makes the terminal standard out whereas just calling the file pipes standard out somewhere else. I can't confirm this hunch tho. – Fenner

On a windows 7 64 bit running Python 2.6.6 output from a batch is printed out to a screen after calling blah.py by itself. – Proto

On my windows 7 32 bit running Python 2.6.6 can not reproduce it. – Nihil

What happens if you explicitly assign stdout in the subprocess call to sys.stdout? – Granese

Add a line to the top of your python file that prints sys.path. I'm wondering if directly invoking the python interpreter is resulting in a different path than calling the file by itself. – Bragg

Vista 32 bit python 2.7.2 cannot reproduce. Also I seem to remember having a similar indecent where argv[0] was one thing when I ran it as ">>python pyfile.py" and another thing when I ran it as ">> pyfile.py" not sure if that has any effect on you or not. – Convincing

What does C:\Python25\python.exe blah.py do? python blah.py will find "python" in PATH and blah.py will use the file association to find the program to use. These won't necessarily find the same program. Putting print sys.version_info at the top of your script might help debugging too. – Unmeaning

Path is the same. sys.version info is the same. Putting sys.stdout explicitly in seems to have worked. – Hyacinthus

ftype won't tell the whole truth as it only reports what's in the HKEY_LOCAL_MACHINE\Software\Classes which might be overridden by entries in HKEY_CURRENT_USER\Software\Classes. See my answer to where in the registry does Windows store, with which program to open certain file types? – Orlena

I am now suspecting that somewhere it may be running with pythonw.exe - the version with no console output. I've yet to find out where this is set though. – Hyacinthus

How did you check the file type association? Run reg query HKCU\Software\Classes\Python.File\shell\open\command /ve and reg query HKLM\Software\Classes\Python.File\shell\open\command /ve to get the full view. – Orlena

Answer 1

I had common problem using threads, but all of my code was in python. Threads can not write to standard output using print. Just main thread could do that. I used somethnig like this

import sys
sys.stdout.write("this was printed by thread")

I know that probably it wont help you with bat file...

Bowfin

This is interesting and probably has a bearing on the way subprocess works - it won't solve the problem, but is related. – Hyacinthus

Threads can not write to standard output using print Why do you think so? – Orlena