Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os: open stdin read-only and stdout/stderr write-only #34909

Open
FiloSottile opened this issue Oct 15, 2019 · 3 comments
Labels
Milestone

Comments

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Oct 15, 2019

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.

@FiloSottile FiloSottile added this to the Go1.14 milestone Oct 15, 2019
@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Oct 15, 2019

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:

hello
<nil>
@mvdan

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented Oct 16, 2019

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.

@slrz

This comment has been minimized.

Copy link

@slrz slrz commented Oct 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.