Re: Separating "shell dir" output from GDB/MI output

[Daniel Jacobowitz <drow@false.org>]

On Sun, Oct 09, 2005 at 01:33:20PM -0400, Bob Rossi wrote:
> > > On 10/9/05, Bob Rossi <bob@brasko.net> wrote:
> > > > I think the best idea we've had so far for solving problems like this is
> > > > to add an option to GDB to have it output GDB/MI data on a file
> > > > descriptor X. For instance,
> > > >    gdb -i=mi -mi-out-fd=30
> > > > and then when you fork/exec GDB you dup the 30 file descriptor so that
> > > > you can read the output.
> > > >
> > > > Eli, do you know if this approach would be portable to windows nativly?
> > > > I could look into implementing this feature, since it would resolve a
> > > > *lot* of problems regarding I/O.
> > 
> > While I think this is a good idea, what other specific problems would
> > it solve that we haven't solved already?
> 
> It solves several problems. The user no longer has to create a pty to
> give to GDB to separate the inferior output and the console output.
> (CGDB will have to anyways, since it uses the terminal).

This one we've already solved, albeit with a bit of extra work on the
part of the frontend (and we were all enthusiastic about the solution,
too...)

> Some of the
> target's apparently write to STDOUT/STDERR, and that get's confused with
> the MI output.

I don't know what you're referring to here.

> Also, thing's like 'shell' and potentially other case's
> get mixed in with the MI output.

Shell's the only one I can think of offhand.

> Finally, if we have several
> interpreters going at the same time, we could have them all output to
> there own descriptor.

This is an interesting idea, but I don't think it's an obviously right
choice.  The CLI frontend wants its own terminal, really.  The MI
interpreter only needs a pipe.  I have use for multiple MI interpreters
running at the same time, which will all need their own pipes, but
that's not a big deal with the infrastructure we already have.

I think wrapping shell's output in MI quoting would be a simpler
solution rather than changing the nature of MI/frontend interaction
again.

-- 
Daniel Jacobowitz
CodeSourcery, LLC