python - 如果没有为 python 解释器打开的终端/控制台窗口，那么标准流到底是什么？

Question

在 Ubuntu Desktop (Unity) 下，当一个脚本被标记为可执行文件，然后我点击该文件时，我会看到如图所示的弹出窗口:

pyscript.py 是一个带有 shebang 的可执行 Python 脚本文件:#!/usr/bin/python 其中 /usr/bin/python 是指向Python 解释器。因为我没有在终端窗口中运行这个过程，因为我只是点击了“运行”，所以我最初认为这个过程没有标准流；随着我尝试更多，我意识到所有标准流都可用:

pyscript.py

#!/usr/bin/python3
import sys, os
f = file=open("output.txt", "w")
print(sys.stdout, sys.stdin, sys.stderr, sep='\n', file=f)

output.txt

<_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
<_io.TextIOWrapper name='<stdin>' mode='r' encoding='UTF-8'>
<_io.TextIOWrapper name='<stderr>' mode='w' encoding='UTF-8'>

这就提出了一个问题，后台没有运行终端窗口，sys.stdout、stdin 和stderr 连接到什么？从技术上讲，在 Windows 下使用 .pyw 运行没有控制台窗口的 Python 我得到相同的输出。

看看这个问题: pythonw.exe or python.exe?

一个答案陈述如下:

Standard streams sys.stdin, sys.stdout and sys.stderr are NOT available.

虽然我在 Windows 10 中通过单击 .pyw 文件在 Windows 10 中使用 Python 2.7 对此进行了测试，但是在 Windows 注册表中 .pyw 文件与在我的机器上运行 pythonw.exe 的 Python 2.X 相关联。

这个问题是 Unix/Windows 的问题!

Answer 1

正如其他人所提到的，这个问题不是特定于 Python 的。生成进程时，父进程有责任设置子进程的文件描述符(或允许它们被继承)。

因此，这甚至不是特定于操作系统的，而是特定于应用程序的。例如，您可能对 Gnome 和 KDE 使用不同的 anser。或者从 Windows 资源管理器或 7-Zip 中执行文件时(我想；我知道这在 Unix 上是如何工作的，但在 Windows 上不太确定)。产生进程的不同应用程序可能会做出不同的安排。

在 Linux 上，您可以通过在 python 进程上运行 lsof 来查找，它将列出打开的文件并告诉您 stdout 的确切去向。这是您的代码，已更改为执行此操作:

#!/usr/bin/env python

# vi: ai sts=4 sw=4 et

import sys, os, pprint
import subprocess

f = open("/tmp/output.txt", "w")

for stream in (sys.stdout, sys.stdin, sys.stderr):
    print (stream, file=f)
    print ("STTY?", stream.isatty(), file=f)
    print ("fileno:", stream.fileno(), file=f)
    print ("name:", stream.name, file=f)

#    print (pprint.pprint(dir(stream)), file=f)
    print (file=f)

subprocess.call ("lsof -p %s" % os.getpid(), stdout = f, shell = True)

只有最后一行才是真正重要的。查看正常运行的输出:

(...)
test.py 29722 xxx    0u   CHR  136,4      0t0      7 /dev/pts/4
test.py 29722 xxx    1u   CHR  136,4      0t0      7 /dev/pts/4
test.py 29722 xxx    2u   CHR  136,4      0t0      7 /dev/pts/4

并且在将输出重定向到文件时:

(...)
test.py 29728 xxx    0u   CHR  136,4      0t0       7 /dev/pts/4
test.py 29728 xxx    1w   REG   0,38        0 2070222 /tmp/asdf.txt
test.py 29728 xxx    2u   CHR  136,4      0t0       7 /dev/pts/4

看到文件 #1 已经改变了吗？当您从 Unity 运行它时，也会发生同样的情况，告诉您它的去向。

我没有完全重现你的问题，因为我的 Gnome 3 文件管理器不会运行那样的脚本，我也不会研究它，但我很想知道你的问题在哪里。