为什么读取 StdoutPipe 会导致输出乱序？

从现在开始，努力学习吧！本文《为什么读取 StdoutPipe 会导致输出乱序？》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

我有以下函数，该函数调用我无法在此处发布的命令。以前我使用 cmd.stdout = os.stdout 在命令行上获取命令输出，如下所示，效果很好：

func run(cmd *exec.cmd) {
    cmd.stdout = os.stdout
    if err := cmd.start(); err != nil {
        panic(err)
    }
    if err := cmd.wait(); err != nil {
        panic(err)
    }
    return
}

这给了我以下命令行输出，这很棒：

[loader] loading programm...
[programm] foo bar

现在我需要先与输出交互，所以我尝试使用 stdoutpipe：

func run(cmd *exec.cmd) {
    stdout, err := cmd.stdoutpipe()
    if err != nil {
        panic(err)
    }
    if err := cmd.start(); err != nil {
        panic(err)
    }
    reader := bufio.newreader(stdout)
    for {
        s, err := reader.readstring('\n')
        if err != nil {
            break
        }
        //  do some evaluation of s here
        fmt.print(s)
    }
    if err := cmd.wait(); err != nil {
        panic(err)
    }
    return
}

但这会打乱消息的顺序，我没有得到以下输出：

[programm] foo bar
[loader] loading programm...

为什么输出不再按顺序排列？如何在使用 stdoutpipe 时保持输出按顺序排列？

编辑： 如果我尝试像这样使用 io.multiwriter ，也会发生同样的情况：

func run(cmd *exec.Cmd) {
    var reader bytes.Buffer
    cmd.Stdout = io.MultiWriter(os.Stdout, &reader)
    if err := cmd.Start(); err != nil {
        panic(err)
    }
    for {
        s, err := reader.ReadString('\n')
        if err != nil {
            break
        }
        fmt.Print(s)
    }
    if err := cmd.Wait(); err != nil {
        panic(err)
    }
    return
}

解决方案

很大程度上取决于您运行的程序。

您noted in a comment认为：

我使用 stdbuf -o0 来停用缓冲

这仅影响程序的 stdout（POSIX 系统上的文件描述符 1），而不影响其 stderr（文件描述符 2）。但 POSIX 系统通常使用以下默认值，至少对于 C 语言程序或使用 C 运行时系统的程序来说是这样：

• stdin：缓冲并不是特别相关，但输入通常会完全缓冲。
• stdout：如果文件描述符 1 是“tty”，则行缓冲；否则完全缓冲。
• stderr：无缓冲。

确定什么是“tty”是通过调用C库isatty函数来完成的，该函数通常使用termios操作来完成此操作。例如，glibc isatty 调用 TCGETATTR 并验证它是否返回且没有错误。 glibc tcgetattr 使用 TCGETATTR ioctl。因此“tty 设备”是实现 TCGETATTR 的设备。

过去使用的实际串行线路（例如 COM1 和 COM2），或者过去使用的终端集中器设备（例如 DH/DM 或 DZ），当然要实现 TCGETATTR 。伪终端也是如此，例如交互式 ssh 会话、script 和其他程序所使用的伪终端。这使得 1970 年代和 1980 年代的所有旧软件能够继续与虚拟化 ASR33、ADM3A 或 DECwriter 一起工作。¹

无论如何，这里的关键是管道（或套接字或类似的东西）不实现 TCGETATTR，因此如果 stdout 是管道，则 isatty(1) 为 0（假）。这使得标准输出完全缓冲。

请记住，这一切都发生在您运行的程序中。您自己的程序读取其他程序的输出（不一定）不是问题。您的程序仅在其他程序实际发送输出时才获取输出。在完全缓冲模式下，其他程序仅在填满缓冲区块或调用某些输出刷新操作时发送输出。

一些程序将输出混合到 stdout - 他们通常假设是行缓冲的，因为编写（有缺陷的）程序的人仅使用 tty 输出对其进行测试 - 并输出到 stderr。当标准输出重定向到文件或管道时，这些程序的行为很奇怪。像 stdbuf 这样的程序（可以作为库预加载实现）和 hence might not work on setuid programs 可以用来解决这些问题。

在 Go 中，缓冲更多地取决于您自己的程序。 Go 不使用 POSIX 设置。例如，请参阅 Idiomatically buffer os.Stdout。

¹我更喜欢我的虚拟 Tek4025、Heathkit H19 等，尽管对于旧的打印终端有一些话要说！或者是旧的 AAA 终端，在斜视模式下最多可显示 60 行。 OK，Terminal、iterm2 等已经打败它们了。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《为什么读取 StdoutPipe 会导致输出乱序？》文章吧，也可关注golang学习网公众号了解相关技术文章。