【问题标题】:"print" not working when redirecting to another application重定向到另一个应用程序时“打印”不起作用
【发布时间】:2015-08-12 09:05:40
【问题描述】:

我在重定向 python 应用程序的输出时遇到了这个奇怪的问题。我正在运行 bitmessage from source,它会在控制台上打印大量内容。

我尝试使用我编写的应用程序过滤掉一些行。当我将输出重定向到文件python.exe src\bitmessagemain.py>file.txt 时,它工作正常,所有内容都发送到文本文件。当我将输出传送到另一个应用程序python.exe src\bitmessagemain.py | someapp.exe 时,所有“打印”语句似乎都被忽略了。它们不会被重定向,也不会被传送到其他应用程序。

在使用“more”和“type CON”等系统内部命令时,重定向甚至不起作用

有人知道如何解决这个问题吗?

【问题讨论】:

  • 我想知道 Windows 是否支持 Unix 风格的管道。是吗?
  • python -c "print('test')" | more 工作吗?
  • @eryksun 是的,它有效
  • 由于more.com 是外部的,因此Python 端可能没有任何问题。 someapp.exe 可以直接从控制台读取,或者如果它检测到 stdin 不是控制台输入,则更改其行为。

标签: python windows redirect printing stdout


【解决方案1】:

所以我通过实验找到了答案。似乎提供命令行开关-u 通过将输出设置为无缓冲二进制模式来解决问题。文档:cmd option -u

我不知道任何副作用,但它似乎完全有效。

由于某种原因,输出缓冲区远大于可见控制台区域的大小。我在一个无限循环中打印文本,当我打印大约半 GB(!)时,输出被刷新。这仅在使用重定向时完成。可能是为了优化性能。

【讨论】:

  • Python 的 print 语句/函数不会在每次写入后刷新文件缓冲区,这就是无缓冲模式解决问题的原因。
  • 通常需要缓冲区来优化写入数据并减少系统调用,并且管道另一端的读取过程检测到 stdin 不是交互式的以适应处理缓冲的 I/O。您还没有描述完整的问题,以说明您正在尝试做什么以及为什么管道的另一端存在默认缓冲问题。
  • 使用无缓冲 IO 的更好方法是在适当的时候使用sys.stdout.flush()
猜你喜欢
  • 2019-05-06
  • 2018-04-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-06-12
  • 1970-01-01
  • 2019-01-12
  • 1970-01-01
相关资源
最近更新 更多