From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8442 invoked by alias); 22 Jan 2015 17:04:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 8415 invoked by uid 89); 22 Jan 2015 17:04:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 22 Jan 2015 17:04:05 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MH3WJQ022573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 12:03:32 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0MH3U9N014065; Thu, 22 Jan 2015 12:03:31 -0500 Message-ID: <54C12D62.7070801@redhat.com> Date: Thu, 22 Jan 2015 17:04:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eli Zaretskii CC: dje@google.com, gdb-patches@sourceware.org Subject: Re: Building the 7.8.90 pretest on MinGW References: <83vbk82fkg.fsf@gnu.org> <83lhkyy84l.fsf@gnu.org> <54C0D965.9000305@redhat.com> <83ppa6vlv1.fsf@gnu.org> In-Reply-To: <83ppa6vlv1.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg00598.txt.bz2 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". See https://sourceware.org/bugzilla/show_bug.cgi?id=17519. 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. Thanks, Pedro Alves