Proposal: Allow DevNull to be used in redirect_stdout

[sbromberger]

Following up on #12050 (comment),

I would like to propose that we change redirect_stdout to allow this:

julia> redirect_stdout(DevNull)
ERROR: MethodError: no method matching redirect_stdout(::Base.DevNullStream)
Closest candidates are:
  redirect_stdout() at stream.jl:1034
  redirect_stdout(::Union{Base.LibuvStream, IOStream}) at stream.jl:1028
  redirect_stdout(::Function, ::Any) at stream.jl:1082

Right now,

DevNull <: DevNullStream <: IO <: Any,
open("/tmp/foo", "w") <: IOStream <: IO <: Any,
STDOUT <: TTY <: LibuvStream <: IO <: Any

The latter two are allowed with redirect_stdout per the second method listed, but DevNull isn't.

(Is there a reason that redirect_stdout can't accept IO? That would resolve this issue and make things more consistent.)

[yuyichao]

Is there a reason that redirect_stdout can't accept IO

Yes, it doesn't work in general.

[sbromberger]

Yes, it doesn't work in general.

Under what circumstances would an IO object not be a suitable candidate for redirect_stdout?

[yuyichao]

Under what circumstances would an IO object not be a suitable candidate for redirect_stdout?

Basically anything that's not a real file.

[sbromberger]

Basically anything that's not a real file.

But that's not accurate: TCPSocket, TTY, and Pipe aren't "real files" and they currently work with redirect_stdout. I'm afraid I'm not following you here.

[yuyichao]

Real file refer to a real file for the OS. All of the above are real files.

[sbromberger]

base64.jl:mutable struct Base64EncodePipe <: IO
base64.jl:mutable struct Base64DecodePipe <: IO
boot.jl:mutable struct CoreSTDOUT <: IO end
boot.jl:mutable struct CoreSTDERR <: IO end
coreio.jl:struct DevNullStream <: IO end
iobuffer.jl:mutable struct AbstractIOBuffer{T<:AbstractVector{UInt8}} <: IO
iostream.jl:mutable struct IOStream <: IO
mmap.jl:mutable struct Anonymous <: IO

Which of these represent "non-real" files that would not be suitable candidates for redirect_stdout?

Honestly, it feels like I'm pulling teeth here.

[vtjnash]

All of them would not be?

[sbromberger]

@vtjnash yet at least some of them are accepted, no? That is,

open("/tmp/foo", "w") <: IOStream <: IO <: Any

is a counterexample.

Assuming I haven't been precise enough in my earlier question, let me rephrase:

What is a concrete example of an IO object not being a suitable candidate for redirect_stdout?

[JeffBezanson]

What Yichao means is that the object needs to have a kernel-level file descriptor. The reason is that this redirects all output from the current process, even data written by C code. So we could potentially support DevNull by opening /dev/null, and passing that file handle.

[sbromberger]

@JeffBezanson thanks - that's what I was looking for. In fact, redirect_stdout(open(/dev/null, "w")) works, but I can't imagine that's platform-independent. How does DevNull do its magic?

[yuyichao]

Also

iostream.jl:mutable struct IOStream <: IO

is not a "non-real" file.

[JeffBezanson]

DevNull just implements the julia I/O interface with functions that do (almost) nothing. IIUC, it is then supported as a special case by the process code, which passes on values to libuv that cause it to do a portable equivalent of opening /dev/null.

[sbromberger]

@JeffBezanson thanks. Since this issue has gone a bit off the rails, I'll close it out and reopen another one with the specific enhancement request.