Steven Silvester

> Would REPLWrapper.run_command() be a reasonable place to check for and strip any bracketing? Sounds right to me

For reference, here is how [`xeus-python`](https://github.com/jupyter-xeus/xeus-python/blob/e8d51d331c3453fc19e5492c4e3af8249f9f11a6/src/xinteractiveshell.cpp#L21) uses the IPython magics directly. However, they are also a Python kernel, as Doug mentioned.

I think it would take some changes to the python magic implementation, but it should in theory be possible to support. I don't have the bandwidth to dive into it...

This is a fundamental limitation of using `pexpect`: `pty` does not distinguish between `stderr` and `stdout`. Using raw `fd`s is a road fraught with peril due to locking. I don't...

I understand, but it is also a fundamental limitation of talking to a spawned process from python. The [bash kernel](https://github.com/takluyver/bash_kernel/pull/10#issuecomment-66528235) has the same limitation.

@dsblank, it could be possible to thread something like that through. @JMurph2015, the [pty](https://docs.python.org/2/library/pty.html) module in core `python` is the one with the limitation.

Yes, it is easy to read it after the fact. Reading from both `stderr` and `stdout` incrementally is the problem.

Also, without a `pty` you can't interrupt the Octave process, so you'd be losing that capability of the kernel as well.

That would mean that `pexpect` would have to depend on an extension module, or we'd also have to replicate much of what `pexpect` is doing and depend on an extension...

`pexpect` would have to be refactored to add an optional handling of stderr if that enhanced module were available. I'm not sure how it would interact with the `.expect()` method....