cmd.StdoutPipe example in go pkg docs does not run in playground-CodePudding

cmd.StdoutPipe example at go documentation: https://pkg.go.dev/os/exec#example-Cmd.StdoutPipe does not run in playground.

https://play.golang.org/p/ek7-_Xa_bN3

Error:

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [IO wait]:
internal/poll.runtime_pollWait(0x7faec2ac4e88, 0x72)
    /usr/local/go-faketime/src/runtime/netpoll.go:234  0x89
internal/poll.(*pollDesc).wait(0xc000074180, 0xc000100000, 0x1)
    /usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:84  0x32
internal/poll.(*pollDesc).waitRead(...)
    /usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).Read(0xc000074180, {0xc000100000, 0x200, 0x200})
    /usr/local/go-faketime/src/internal/poll/fd_unix.go:167  0x25a
os.(*File).read(...)
    /usr/local/go-faketime/src/os/file_posix.go:32
os.(*File).Read(0xc00000e028, {0xc000100000, 0x28, 0xc000060e80})
    /usr/local/go-faketime/src/os/file.go:119  0x5e
encoding/json.(*Decoder).refill(0xc00007e000)
    /usr/local/go-faketime/src/encoding/json/stream.go:165  0x17f
encoding/json.(*Decoder).readValue(0xc00007e000)
    /usr/local/go-faketime/src/encoding/json/stream.go:140  0xbb
encoding/json.(*Decoder).Decode(0xc00007e000, {0x4cf580, 0xc00000c048})
    /usr/local/go-faketime/src/encoding/json/stream.go:63  0x78
main.main()
    /tmp/sandbox2294589397/prog.go:24  0x185

Program exited.

Locally it's running correctly, no deadlock. I am not able to understand why deadlock happens in go playground.

CodePudding user response：

From the documentation on the os.exec package (which is where this example comes from):

Note that the examples in this package assume a Unix system. They may not run on Windows, and they do not run in the Go Playground used by golang.org and godoc.org.

That note doesn't provide a reason, but the reason is presumably that allowing user-provided unix commands to run would give a broader attack surface for malicious code. It's not that it's impossible to allow this in a relatively secure way, but there's various tradeoffs which make disallowing os.exec a natural choice.