Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upNeed a way to close standard output #40032
Comments
alexcrichton
added
A-io
labels
Feb 22, 2017
steveklabnik
added
the
C-enhancement
label
Feb 22, 2017
This comment has been minimized.
This comment has been minimized.
|
For Windows it’s Nul Device Driver and SetStdHandle AFAICT. |
steveklabnik
added
T-libs
and removed
A-libs
labels
Mar 24, 2017
Mark-Simulacrum
removed
the
A-io
label
Jun 25, 2017
Mark-Simulacrum
added
C-feature-request
and removed
C-enhancement
labels
Sep 10, 2017
dtolnay
added
C-feature-accepted
and removed
C-feature-request
labels
Nov 16, 2017
This comment has been minimized.
This comment has been minimized.
|
Seems reasonable to me. I would be interested in seeing an implementation of this in a PR. |
added a commit
to zackw/rust
that referenced
this issue
Nov 17, 2017
zackw
referenced this issue
Nov 17, 2017
Closed
Partial implementation of `close` for stdin/out/err (#40032) #46063
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
zackw commentedFeb 22, 2017
It is sometimes appropriate for a program to close its standard output stream long before it's done running. For instance, I have a C program that sets up some system-wide state, waits for its parent to be done using that setup, and then tears it down again. (It's a separate program from the parent because it has to be setuid.) It notifies the parent that it's done setting up by closing its stdout, which is expected to be a pipe.
You can do this in Rust, but only by going behind the stdlib's back and calling
libc::close(1). I would like there to be an official way to do this, without going behind the stdlib's back. A concrete proposal:Stdout(andStderr) add aclosemethod. These flush buffered output, close the underlying OS-level file descriptor, and then immediately reopen it on/dev/null, taking care to ensure that the well-known fd number is retained. It remains OK to useio::stdout()after callingcloseon it.(Reopening the OS-level file descriptor on
/dev/nullis to accommodate third-party libraries that may assume it is always safe to write to file descriptors 1 and/or 2, and/or that theopen()primitive will never return descriptors numbered 0, 1, or 2.)(Windows doesn't exactly have "file descriptors" but it does have the concept of "standard handles" and there is a 1:1 mapping from the Unixy terms I used above to Windows equivalents.)
(For consistency, the internal method for "replacing
StdoutandStderrwith an arbitrary instance ofWrite" (mentioned in #40007) should also perform thiscloseoperation.)