os/exec: when NoInheritHandles is set with a handle on Stdout or Stderr, executed command fails

[zhaoya881010]

go version 1.16 windows/386

	out, err := os.OpenFile("test.out", os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0766)
	c := exec.Command("cmd", "/C", "dir")
	c.Stdout = os.Stdout // OK
	//c.Stdout = out // Error
	c.SysProcAttr = &syscall.SysProcAttr{NoInheritHandles: true}
	c.Start()
	c.Wait()

if use c.Stdout = out,c.Wait() return error exit status 1

[mknyszek]

Is the problem here that NoInheritHandles is causing some sort of failure in the subprocess because the stdout handle isn't being propagated correctly?

I'm actually not sure what NoInheritHandles is supposed to guarantee here; I could see it implying that no handles are passed through at all -- you get a "bare" process in some sense that needs to set things up itself. But, I don't know enough about this to say.

CC @ianlancetaylor @bradfitz via https://dev.golang.org/owners

[mknyszek]

I think it would be useful to get more information about what the behavior is that you expect in this scenario.

[mknyszek]

Also, is this windows/386? win32 could technically also mean windows/arm.

[zhaoya881010]

windows/386,i need NoInheritHandles set true and Redirection stdout,stderr to file.

[networkimprov]

cc @alexbrainman @mattn @zx2c4

@gopherbot remove WaitingForInfo

[zx2c4]

This is intended behavior. Everything is working as expected. There is no bug here.

HOWEVER, if what you're looking for is that handles you don't specify aren't accidentally leaked to the child process, that will be the case in Go 1.17.

So: you can probably close this bug, and just wait til 1.17 to get the behavior you desire. I agree 1.16's semantics are worrisome, and understand why you would want this, which is why it's been changed. But for 1.16, that's how it is.

[zhaoya881010]

@zx2c4 ok，expecting 1.17.

[qmuntal]

Can confirm this is working as expected, the child process can't write its output to stdout if it is not inherited.