os/exec: fix StdinPipe and maybe StdoutPipe

[robpike]

See also issue #4290.

StdinPipe (for instance) returns a WriteCloser but then closes it in Wait. That's bad
design: a package that returns a Closer shouldn't then close it for you silently.

But the real problem is that this property makes it impossible to use StdinPipe
correctly to deliver data to the process, since any program attempting to write to the
pipe to deliver input to the process must close the file descriptor itself to signal
EOF. There is a deadly embrace: The process won't exit until EOF; the EOF won't be
delivered until the process exits.

I believe StdinPipe should be deprecated, and a new method (call it XXX) that returns a
WriteCloser, but that Wait does not close that file descriptor. It would be the
well-documented responsibility of the client to close XXX explicitly.

I haven't thought through StdoutPipe but perhaps it has a related issue.

[robpike]

Comment 1:

New possibility: Have StdinPipe return a custom WriteCloser that closes only once (under
lock of course). That way either the client can close or or Wait can, race- and
problem-free. This would require no API change.

Labels changed: added go1.2, removed go1.2maybe.

[adg]

Comment 3:

Owner changed to @adg.

Status changed to Started.

[bradfitz]

Comment 4:

Re comment #1: I proposed that 10 months ago:
https://golang.org/cl/6789043/#msg7
But there was concern that we couldn't change the underlying type away from being an
*os.File: https://golang.org/cl/6789043/#msg8 etc

[adg]

Comment 5:

This issue was closed by revision 10e2ffd.

Status changed to Fixed.