Apparently at least macOS will let you write to stdin (and iTerm2 will show the output! Even if stdout/stderr are redirected!) but that's probably always an application error.
Sounds like we can save developers some debugging by opening those file descriptors read/write only.
Here's a playground snippet writing to os.Stdin:
https://play.golang.org/p/KRsTZeUNDrx
It reports an error on the playground:
write /dev/stdin: Bad file number
But works without error on macOS and Linux:
<nil>
I'm horrified that this restriction wasn't always in place. If we want to give it a try for 1.14, I assume we want to do that the sooner the better, to catch any regressions during the freeze and betas.
This is nothing specific to Go and just standard system behaviour, right? It's not the Go runtime that is opening these file descriptors and we have no idea what programs might use them for. It's the same thing as programs calling seek on stdout. Distasteful for a general purpose program but not necessarily wrong (e.g. if you control the parent and the child processes).
Even ignoring the compatibility implications of changing this long-standing behaviour, I think it's a bad idea to start messing with the FDs inherited from the parent process in this way. It just results in a system that is opaque and hard to understand. Certainly too much magic for my taste.
We don't open these descriptors. We don't have any support in the os package for "this file is only available for read access even though the descriptor is writable." So this is more like a feature request than a bug fix.
Most helpful comment
This is nothing specific to Go and just standard system behaviour, right? It's not the Go runtime that is opening these file descriptors and we have no idea what programs might use them for. It's the same thing as programs calling seek on stdout. Distasteful for a general purpose program but not necessarily wrong (e.g. if you control the parent and the child processes).
Even ignoring the compatibility implications of changing this long-standing behaviour, I think it's a bad idea to start messing with the FDs inherited from the parent process in this way. It just results in a system that is opaque and hard to understand. Certainly too much magic for my taste.