As I understand it, the REPL makes a private copy of the output-stream descriptors early on, which is why you can't redirect them. This is actually quite useful behavior, because otherwise it would be impossible to debug code using redirect_stdout etc. in the REPL (because the REPL would stop working as soon as you redirect). (The REPL also needs to be able to talk to the terminal at a lower level than just stdout in order to support things like line editing.) Also note that the REPL is a program written in Julia, not a part of the Julia language or standard library, so you wouldn't necessarily expect to see documentation of the REPL's low-level terminal-communication internals.
On Wednesday, July 16, 2014 8:48:11 PM UTC-4, Laszlo Hars wrote: > > I don't know, how to file an issue. Where can I get instructions? (The > STDERR behavior may be intentional. I kept asking about it in this group, > for months, but nobody was interested.) > The difficulty here is that you are trying to hack the REPL for a task to which it is poorly suited. Multiple alternative suggestions have been offered for better ways to communicate between Julia and an external process, but you've rejected them. Basically, you should set up a channel to receive messages, execute the code yourself, catch errors yourself, and then you can do whatever you want with the output, rather than trying to intercept it from the REPL. We didn't write all of your code for you, but we gave enough examples that you should be able to implement what you need. Note that this is independent from whether you want the REPL to be running too, in order to be able to use Julia interactively with the same data. Just run your receive-execute-respond loop in another thread (asynchronous task), and you can have the REPL running at the same time. Another example is IJulia, which receives messages with Julia code from another process (the IPython front-end) and then sends back the results, including errors. IJulia never invokes the REPL at all.
