RFC: writesto(cmd) do io ... end

[stevengj]

There was a recent thread on the mailing list about how to use a pager like less in the REPL. I was curious to see how we would page to less directly, and it took me a bit more digging than I would have liked.

This patch simplifies writing to a process by adding a new method to writesto that takes a function f(io), much like open and friends, so that you can do e.g.

writesto(`less`, STDOUT) do io
      for i = 1:2000
          println(io, i)
      end
end

to page output through less.

(I thought about a different name, like writeall, but overloading writesto makes it easier to discover the alternative asynchronous form of writesto.

An alternative would be to overload open to either read or write from a command. But in this case I would get rid of writesto and readsfrom entirely and replace them by open(cmd, "w") and open(cmd, "r").

[IainNZ]

I kinda like the open suggestion because it wouldn't require exporting a new name. The idea is a good one though!

[stevengj]

@IainNZ, the names writesto and readsfrom are already exported. But I'm warming to the idea of deprecating these and replacing them with open ... they both return the same types (Pipe,Process), so type-stability isn't an issue.

The open idea only occurred to me after submitting this patch. If others like the idea of deprecating readsfrom and writesto, I will close this and submit a new patch.

cc: @loladiro

[StefanKarpinski]

I also prefer overloading open. The writesto and readsfrom names are not awesome. Another issue, however, is readandwrite which let's you both read and write to/from a command.

[stevengj]

We could support readandwrite too with open(cmd, "r+"). The only issue is that readandwrite currently returns two Pipe objects (one for reading, and one for writing). To fix this, one option could be to generalize the Pipe object so that a single Pipe can be used for both reading and writing (which would be much closer to how other read/write IO streams are handled).

[StefanKarpinski]

That's probably a good approach, although I do prefer the approach of separating duplex stream objects into two handles. But that's not what UNIX TCP sockets or libuv do so we should probably just follow suit and support that kind of duplex stream object.