From: Daniel Jacobowitz <drow@false.org>
To: "jingzhao.ou" <jingzhao.ou@gmail.com>
Cc: gdb@sources.redhat.com
Subject: Re: Separating "shell dir" output from GDB/MI output
Date: Sun, 09 Oct 2005 17:12:00 -0000 [thread overview]
Message-ID: <20051009171225.GA4295@nevyn.them.org> (raw)
In-Reply-To: <b5706cf10510091004r205783ddoc36645fc59138f39@mail.gmail.com>
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
next prev parent reply other threads:[~2005-10-09 17:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-09 5:19 jingzhao.ou
2005-10-09 12:33 ` Bob Rossi
2005-10-09 17:04 ` jingzhao.ou
2005-10-09 17:12 ` Daniel Jacobowitz [this message]
2005-10-09 17:33 ` Bob Rossi
2005-10-09 20:02 ` Daniel Jacobowitz
2005-10-09 20:19 ` Bob Rossi
2005-10-09 20:26 ` Daniel Jacobowitz
[not found] ` <b5706cf10510091145v5bfa03ben44f62981f174c4a2@mail.gmail.com>
2005-10-09 18:47 ` jingzhao.ou
2005-10-09 20:04 ` Daniel Jacobowitz
2005-10-10 8:41 ` Re[2]: " Konstantin Karganov
2005-10-15 12:29 ` Eli Zaretskii
2005-10-15 12:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051009171225.GA4295@nevyn.them.org \
--to=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=jingzhao.ou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).