【问题标题】:What is the point of "stderr" in Python?Python中的“stderr”有什么意义?
【发布时间】:2018-11-21 22:16:19
【问题描述】:

我是一名编程新手,我正在尝试了解 stdinstdoutstderr 的工作原理。据我了解,stdoutstderr 是我们可以直接从程序输出的两个不同位置。我想我不明白仅仅因为stderr 的错误而输出第二个“流”有什么意义?为什么常规stdout 上没有错误? stderr 出现错误让我可以做什么(基本上为什么 stderr 有用)?

【问题讨论】:

  • 您可能想忽略标准输出,而不是标准错误。分离流允许您这样做,无论是记录、解析程序输出等。
  • Wiki: '标准错误是程序通常用于输出错误消息或诊断的另一种输出流。它是一个独立于标准输出的流,可以单独重定向。这解决了半谓词问题[...]' stderr 的要点是不要猜测而是知道输出什么以及错误代码是什么。
  • 这是一个方便和连贯的问题,它与给您的用户的信息和崩溃消息不同
  • 其实我在 Python 上看不到这个问题的任何细节,它几乎是相同的概念,独立于编程语言。

标签: python error-handling stdout stdin stderr


【解决方案1】:

支持不同的 stout 和 stderr 流有两个“点”:

  1. 当您编写可以链接在一起的应用程序(例如使用管道)时,您不希望“正常”输出与错误、警告、调试信息和其他“闲聊”混为一谈。将它们混合在同一个流中会使链/管道中的下一个程序变得困难。

    例子:

    $ cat 一些文件 |不是 $ 回声 $?

    如果cat 命令没有将其错误消息写入标准错误,那么如果"some-file" 不存在,grep 命令将看到"file not found" 消息。然后它将(错误地)匹配“不”,并错误地设置管道的返回码。构建处理此类事情的管道将是非常困难

  2. 从……嗯……1970 年代开始,(至少)UNIX 和类 UNIX 系统就支持单独的 stdout 和 stderr 流。它们是 POSIX 标准的一部分。如果一种新的编程语言的运行时库不支持这一点,那么它就会被认为是残缺的;即不适合编写生产质量应用程序。

    (在编程语言的历史上,Python 还是比较新的。)

但是,没有人会强迫您编写应用程序以将 stderr 用于其预期目的。 (嗯......也许你未来的同事会:-))

【讨论】:

  • 从技术上讲,语言的运行时不必支持它。该进程(无论如何,在 POSIX 模型下)会发现它在启动时打开了两个文件以供写入。该语言是否为其中一个或两个文件描述符提供默认绑定是方便的问题,而不是正确性的问题。
  • 正确。从技术上讲,它没有。但是,我会完全拒绝使用任何出现此错误的现代 PL ......除了玩具程序之外的任何东西。 (违背惯例的语言......没有充分的理由......不倾向于生存。)
  • 我的意思是,即使 Python 没有提供sys.stdout,你也可以使用stdout = open(1, "w") 自己定义。这不是由 Python 提供的,而是由运行 Python 实现的平台提供的。
  • (尽管在某些时候,我猜该语言必须提供一些工具来访问继承的文件描述符,所以我承认这一点。)
  • 假设。但是你假设你可以做open(1, "w")。例如,您不能在没有将 fd 值公开为整数的语言中执行此操作。例如,Java。但这是假设的,因为 Python 确实 支持 stderr。而我真正的观点​​是,不正确支持 stderr 的 PL 将无法生存。
【解决方案2】:

在 UNIX(和 Linux,以及其他与 Posix 兼容的系统)中,程序通常与管道结合使用,因此一个程序将另一个程序的输出作为输入。如果您将正常输出和错误信息混合在一起,则每个程序都需要知道如何将来自其管道数据生产者的诊断信息与正常数据区别对待。在实践中,这是不可能的,因为有大量的程序组合。 通过将错误信息写入 stderr,每个程序都可以让用户获得此信息,而无需将其从管道中的下一个程序读取的数据流中过滤掉。

【讨论】:

  • 管道只是众多重定向操作之一。我隐约记得cat nosuchfile >stdout 比管道还要古老。
猜你喜欢
  • 2015-02-03
  • 2010-11-04
  • 1970-01-01
  • 2022-07-31
  • 2011-05-22
  • 2015-01-17
  • 1970-01-01
  • 2011-09-20
  • 1970-01-01
相关资源
最近更新 更多