Windows - запуск .py напрямую по сравнению с запуском python blah.py ведет себя по-разному

У меня есть скрипт Python, который использует подпроцесс:

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

Если это было названо blah.py, и я запускаю (из командной строки):

python blah.py

Я получу вывод из do_stuff.bat (или того, что я запускаю).

Если это выполняется как:

blah.py

Тогда я не получаю вывод из do_stuff.bat, только операторы печати.

Пока видел на Windows Server 2003. Python версии 2.5.2 (застрял там по разным причинам). Глядя на действие связанного типа файла, я вижу:

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

Так кто-нибудь может объяснить разницу?


python windows subprocess
person Danny Staple    schedule 18.08.2011    source источник
comment
Я бы рискнул предположить и сказать, что явный вызов python делает стандарт терминала, тогда как простой вызов стандарта файловых каналов где-то еще. Я не могу подтвердить эту догадку.   -  person Exelian    schedule 18.08.2011
comment
В 64-разрядной версии Windows 7 с Python 2.6.6 вывод из пакета выводится на экран после вызова blah.py сам по себе.   -  person Helbreder    schedule 18.08.2011
comment
На моей Windows 7 32-битная версия Python 2.6.6 не может ее воспроизвести.   -  person Nicolae Dascalu    schedule 18.08.2011
comment
Что произойдет, если вы явно назначите стандартный вывод в вызове подпроцесса для sys.stdout?   -  person vsekhar    schedule 18.08.2011
comment
Добавьте строку в начало файла Python, которая печатает sys.path. Мне интересно, приводит ли прямой вызов интерпретатора python к другому пути, чем вызов файла сам по себе.   -  person g.d.d.c    schedule 18.08.2011
comment
32-битный Python 2.7.2 Vista не может воспроизводиться. Также я, кажется, помню, что у меня было подобное неприличное, где argv[0] было одно, когда я запускал его как ››python pyfile.py, и другое, когда я запускал его как ››pyfile.py, не уверен, что это как-то повлияет на вас или нет.   -  person John    schedule 19.08.2011
comment
Что делает C:\Python25\python.exe blah.py? python blah.py найдет python в PATH, а blah.py будет использовать ассоциацию файлов, чтобы найти программу для использования. Они не обязательно найдут ту же программу. Помещение print sys.version_info в начало вашего скрипта также может помочь при отладке.   -  person Peter Graham    schedule 19.08.2011
comment
Путь тот же. Информация sys.version такая же. Кажется, сработало явное включение sys.stdout.   -  person Danny Staple    schedule 19.08.2011
comment
ftype не скажет всей правды, так как сообщает только то, что находится в HKEY_LOCAL_MACHINE\Software\Classes, что может быть переопределено записями в HKEY_CURRENT_USER\Software\Classes. См. мой ответ на где в реестре Windows хранит, какой программой открывать определенные типы файлов?   -  person Piotr Dobrogost    schedule 20.09.2011
comment
Теперь я подозреваю, что где-то он может работать с pythonw.exe - версией без вывода на консоль. Я еще не выяснил, где это установлено, хотя.   -  person Danny Staple    schedule 20.09.2011
comment
Как вы проверили ассоциацию типов файлов? Запустите reg query HKCU\Software\Classes\Python.File\shell\open\command /ve и reg query HKLM\Software\Classes\Python.File\shell\open\command /ve, чтобы получить полное представление.   -  person Piotr Dobrogost    schedule 23.04.2012

Ответы (1)


arrow_upward
1
arrow_downward

У меня была общая проблема с использованием потоков, но весь мой код был на питоне. Потоки не могут записывать в стандартный вывод с помощью печати. Только основной поток может это сделать. Я использовал что-то вроде этого

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

Я знаю, что, вероятно, это не поможет вам с файлом bat ...

person Jazzuell    schedule 19.08.2011
comment
Это интересно и, вероятно, имеет отношение к тому, как работает подпроцесс - это не решит проблему, но связано. - person Danny Staple; 19.08.2011
comment
Потоки не могут записывать в стандартный вывод с помощью print Как вы думаете, почему? - person Piotr Dobrogost; 21.09.2011