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

[Daniel Jacobowitz <drow at false dot org>]

On Sun, Oct 09, 2005 at 10:04:36AM -0700, jingzhao.ou wrote:
> I have another problem with MI. I want to provide a GDB console in my
> application so that the user can work with GDB directly if needed.
> However, if I enable the MI interpreter, the normal GDB output is
> suppressed. I hope that two interpreters can work at the same time and
> their outputs are directed to two different output file descriptors.
> This would give me exactly what I want and all I need. :-)

We're a long way from being able to have multiple interpreters active
at the same time.  I agree it would be a good feature to have, and I've
got other uses for it (in scripting).

For now, for a console, you can use -interpreter-exec and get things
more or less right.  You can find a lot more about this in the list
archives, e.g. Apple's console-quoted hack.

> 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?

A simpler and more specific solution for this particular problem would
be to run "shell" through pipes and MI encapsulate its output, to
prevent it from playing with the user's terminal.  I think that's a
good idea anyway. Right now, you can probably use interactive commands
via shell, but I believe that most uses of it are for things like ls,
grep, or make.

-- 
Daniel Jacobowitz
CodeSourcery, LLC