This is the mail archive of the
mailing list for the GDB project.
Re: Building the 7.8.90 pretest on MinGW
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: dje at google dot com, gdb-patches at sourceware dot org
- Date: Thu, 22 Jan 2015 17:03:30 +0000
- Subject: Re: Building the 7.8.90 pretest on MinGW
- Authentication-results: sourceware.org; auth=none
- References: <announce dot 20150113122445 dot 36DDE48E8A at joel dot gnat dot com> <83vbk82fkg dot fsf at gnu dot org> <CADPb22TWRH+EBxr6i_kKX2NuVy9Gczo3v=FUWQGOFZqD9SpELA at mail dot gmail dot com> <83lhkyy84l dot fsf at gnu dot org> <54C0D965 dot 9000305 at redhat dot com> <83ppa6vlv1 dot fsf at gnu dot org>
On 01/22/2015 04:08 PM, Eli Zaretskii wrote:
>> A couple questions though:
>> The "cup" check is there to make sure that e.g., starting GDB
>> in a shell within emacs doesn't result in a messed up session.
>> Did you try that?
> You mean, start GDB under Emacs as
> gdb -tui -i=mi ...
No, I mean, start a shell buffer in emacs, start gdb within that,
and do "layout src".
Could you try that?
> ? It's a strange thing to do, but I did try it now, and didn't see
> any problems. Which isn't surprising: Emacs injects "TERM=emacs" into
> the environment inherited by GDB, so the Windows ncurses driver
> doesn't activate itself.
>> I imagine that cases like when stdin is a pipe, like e.g., when
>> starting mingw gdb in a cygwin shell or in a cygwin ssh session, may
>> result in a messed up screen.
> Why would it? pipes fail the isatty test.
Right. I recalled that Windows isatty returns true on all
sorts of character devices, like serial ports or the NUL device,
not just consoles, but confused pipes. Pipes are not one of
those. I see that gnulib has a isatty module that checks that
exactly -- it uses GetConsoleMode to make sure input is a real
console handle. We don't import that gnulib module presently, but
if we need that console check it sounds like importing that
module would be way to fix it.