.pyw和pythonw不能在Windows 7下運行

運行一個簡單的.py或.pyw python文件會導致python.exe顯示在任務管理器下。.pyw和pythonw不能在Windows 7下運行

python myApp.py 
python myApp.pyw

然而，當我們試圖不使用控制檯運行，該腳本不會出現跑，也不python.exe或pythonw.exe下任務管理器

pythonw myApp.pyw 
pythonw myApp.py

出現我們如何解決這個問題呢？該系統運行Python 2.7.8 x64。

來源

2014-07-18 Nyxynyx

你有沒有解決過這個問題？我用我的劇本面對完全相同的事情。按照Ross的答案寫出stderr/stdout表明腳本*不會啓動，而是在不拋出異常的情況下死亡。 – mfitzp

@mfitzp：您需要將sys.stderr作爲業務的第一順序重定向到文件，否則會丟失未處理異常的錯誤消息;看到我的答案。 – mklement0

林不知道我理解你的問題，但我認爲這是你需要知道

你需要右鍵單擊一個PY或pyw文件，並選擇與...找到python.exe（可能爲C開什麼：\ Python27 \ python.exe）..檢查總是打開的框...現在，如果您想要運行它，現在只需雙擊它即可

（通常安裝程序會爲您設置它...）

來源

2014-07-18 23:34:42

問題不在於文件關聯;問題是腳本在默認情況下在使用'pythonw.exe'而不是'python.exe'調用未處理的異常時會失敗。 – mklement0

嘗試添加行import sys; sys.stderr = open("errlog.txt", "w")到myApp.py的開頭。然後在errlog.txt中查找追溯或任何其他錯誤消息。

來源

2014-07-19 02:37:03

我在自己的腳本上面臨同樣的問題，發現在添加Ross的答案輸出時，腳本實際上會運行。

看來出於某種原因，重定向輸出可以解決問題。由於我不是有意寫輸出到磁盤我，而不是它寫入/dev/null（或平臺等效）：

if (sys.platform == 'win32' and sys.executable.split('\\')[-1] == 'pythonw.exe'): 
    sys.stdout = open(os.devnull, 'w') 
    sys.stderr = open(os.devnull, 'w')

的if語句確保當腳本是從pythonw.exe啓動時纔會發生。我不確定它是否相關，但是在其他進口產品之前這樣做很重要（包括例如import logging）。

來源

2014-10-01 19:02:47 mfitzp

是的，這解決了這個問題，因爲當腳本使用'pythonw.exe'運行時，'sys.stdin'，'sys.stdout'和'sys.stderr'具有_invalid_文件描述符（2.x），或是「無」（3.x）。但是，我建議將_stderr_重定向到一個實際的文件，這樣如果腳本由於未處理的異常而死掉，至少可以找出原因。 – mklement0

我有類似的問題。

通過寫入日誌文件逐步調試後，我發現pythonw.exe在試圖使用調用的語句後崩潰：sys.stdout.write（）。事實證明，當用pythonw.exe運行時，sys.stdout是None。

如果您使用的是sys.stdout/stderr/stdin的函數，並且打算在pythonw.exe中使用您的程序，那麼添加「None」的檢查是一個好主意。

來源

2015-01-27 18:05:51 Amol

TL;博士

上調用

要排查，使用輸出重定向：

pythonw myApp.py 1>stdout.txt 2>stderr.txt

這將捕獲的stdout輸出，例如從print()，在文件stdout.txt和stderr輸出（例如來自未處理的例外），文件stderr.txt;從PowerShell，使用
cmd /c pythonw myApp.py 1>stdout.txt 2>stderr.txt）。
注意重定向標準輸出的非常行爲實際上可能再次使你的腳本工作，如果其與pythonw失敗的唯一原因是利用print（在Python 2.x的 - 見下文）。
買者：調用*.pyw腳本時，此輸出重定向技術看似不不工作直接（如通過將腳本文件路徑pythonw.exe反對）。 ^{如果你知道爲什麼和/或它是否適合你，請告訴我。}

要解決您的腳本：

發生在要運行與pythonw.exe任何的Python 2.x或3.x的腳本的頂部以下內容：

import sys, os 
if sys.executable.endswith("pythonw.exe"): 
    sys.stdout = open(os.devnull, "w"); 
    sys.stderr = open(os.path.join(os.getenv("TEMP"), "stderr-"+os.path.basename(sys.argv[0])), "w")

當使用運行腳本時，可以確保以下內容：

print()調用和顯式調用sys.stdout()實際上被忽略（不-OPS）。
Stderr輸出，包括來自未處理的致命異常，發送到文件 %TEMP%\stderr-<scriptFileName>; %TEMP%是一個標準的Windows環境變量，指向當前用戶的臨時文件的文件夾。

換句話說：有了上面的代碼，檢查文件%TEMP%\stderr-<scriptFileName>後當pythonw.exe調用的腳本已經默默地失敗。

有關解釋，請繼續閱讀。

在Windows上，pythonw.exe是啓動GUI /無UI不惜一切的腳本，這意味着的標準輸入和輸出流 - sys.stdin，sys.stdout，sys.stderr不可用。

這有2討厭的副作用：

使用print() - 它的目標sys.stdout默認 - 導致在Python 2.x的異常。
- 此問題已在Python 3.x中修復。
任何未處理的異常 - 包括在2中由print()觸發的一個異常。x - 導致腳本無聲地中止。
- 默認情況下，異常錯誤消息轉到sys.stderr，這是此場景中不可用的情況。 - 無論是明確，或隱式地通過print()
  - 發送標準輸出輸出到空設備，有效地忽略任何嘗試，以輸出到sys.stdout：
上面的代碼通過固定這些問題。
將所有stderr輸出發送到臨時文件。

的Python 2.x和Python 3.x都有差異：

當一個腳本與pythonw.exe，sys.stdin，sys.stdout，並sys.stderr運行：在Python

2.x：有無效 fil Ë描述

試圖寫sys.stdout或sys.stderr時最終結果是出現以下異常：IOError: [Errno 9] Bad file descriptor

陷阱：由於輸出緩衝，這種異常可能不是表面，直到你輸出，說，4K字節;您可以通過調用pythonw.exe和-u（用於無緩衝輸出）立即激發它。

print()盲目地嘗試sys.stdout（默認情況下），所以它遲早會引發這個異常。

在Python 3.X：是設置爲None

這是補充與3.X print()功能進行無操作（什麼都不做），當它發現sys.stdout爲None，所以print()聲明可以默認安全地使用 - 它們將簡單地被忽略當與pythonw.exe運行時

然而，試圖使用sys.stdout.write()和sys.stderr.write()仍然導致異常。

更多背景信息，請參閱here。

來源

2015-05-18 18:14:38 mklement0

這是一個古老的答案，但我要在這裏留下我的解決方案也：

打開CMD（使用提升的權限或不 - 取決於你的需要）
更改到的.py目錄/ .pyw腳本 - 這是很重要的

運行pythonw與腳本參數

cd E:\my\script\folder\ 
pythonw script.py

來源

2017-02-08 08:48:32

升級到我的電腦RAM後，我遇到了類似的問題。原來我不得不重新安裝Pillow（用於圖像處理的庫）。因此，請確保它已安裝，如果不是，請使用cmd中的「pip install Pillow」進行安裝。

來源

2017-07-19 19:38:10 akd

.pyw和pythonw不能在Windows 7下運行

回答

相關問題