在使用子进程和通过管道阅读stdout时，我注意到了一些有趣的行为。
如果我使用io.Pipe()读取通过os/exec创建的子进程的stdout，即使到达EOF（进程完成），从该管道阅读也会永远挂起：

cmd := exec.Command("/bin/echo", "Hello, world!")
r, w := io.Pipe()
cmd.Stdout = w
cmd.Start()
io.Copy(os.Stdout, r) // Prints "Hello, World!" but never returns

但是，如果我使用内置的方法StdoutPipe()，它就可以工作：

cmd := exec.Command("/bin/echo", "Hello, world!")
p := cmd.StdoutPipe()
cmd.Start()
io.Copy(os.Stdout, p) // Prints "Hello, World!" and returns

深入研究/usr/lib/go/src/os/exec/exec.go的源代码，我可以看到StdoutPipe（）方法实际上使用了os.Pipe()，而不是io.Pipe()：

pr, pw, err := os.Pipe()
cmd.Stdout = pw
cmd.closeAfterStart = append(c.closeAfterStart, pw)
cmd.closeAfterWait = append(c.closeAfterWait, pr)
return pr, nil

这给了我两个线索：
1.文件描述符在某些点被关闭。关键的是，管道的“写”端在进程开始之后被关闭。
1.这里使用的不是我上面使用的io.Pipe()，而是os.Pipe()（一个较低级别的调用，大致Map到POSIX中的pipe(2)）。
然而，我仍然无法理解为什么我的原始示例在考虑了这些新发现的知识后会表现出这样的行为。
如果我试图关闭io.Pipe()（而不是os.Pipe()）的写端，那么它似乎完全中断了它，并且没有任何内容被读取（就好像我正在从一个封闭的管道中阅读，尽管我认为我已经将它传递给了子进程）：

cmd := exec.Command("/bin/echo", "Hello, world!")
r, w := io.Pipe()
cmd.Stdout = w
cmd.Start()
w.Close()
io.Copy(os.Stdout, r) // Prints nothing, no read buffer available

好吧，我猜io.Pipe()与os.Pipe()有很大的不同，并且可能不像Unix管道那样，一个close()不会为每个人关闭它。
只是为了让你不要认为我在要求快速修复，我已经知道我可以通过使用以下代码实现预期的行为：

cmd := exec.Command("/bin/echo", "Hello, world!")
r, w, _ := os.Pipe() // using os.Pipe() instead of io.Pipe()
cmd.Stdout = w
cmd.Start()
w.Close()
io.Copy(os.Stdout, r) // Prints "Hello, World!" and returns on EOF. Works. :-)

我想问的是 * 为什么io.Pipe（）似乎忽略了来自编写器的EOF *，让读取器永远阻塞？一个有效的答案可能是io.Pipe()是错误的工具，因为$REASONS，但我不能弄清楚那些$REASONS是什么，因为根据文档，我试图做的似乎完全合理。
这里有一个完整的例子来说明我在说什么：

package main
import (
  "fmt"
  "os"
  "os/exec"
  "io"
)
func main() {
  cmd := exec.Command("/bin/echo", "Hello, world!")
  r, w := io.Pipe()
  cmd.Stdout = w 
  cmd.Start()
  io.Copy(os.Stdout, r) // Blocks here even though EOF is reached
  fmt.Println("Finished io.Copy()")
  cmd.Wait()
}