From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17136 invoked by alias); 30 Nov 2006 11:51:48 -0000 Received: (qmail 17117 invoked by uid 22791); 30 Nov 2006 11:51:46 -0000 X-Spam-Check-By: sourceware.org Received: from out2.smtp.messagingengine.com (HELO out2.smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Nov 2006 11:51:36 +0000 Received: from db2.internal (db2.internal [10.202.2.12]) by out1.messagingengine.com (Postfix) with ESMTP id 994E34926A; Thu, 30 Nov 2006 06:51:35 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by db2.internal (MEProxy); Thu, 30 Nov 2006 06:51:35 -0500 Received: from [192.168.0.2] (202-161-10-95.dyn.iinet.net.au [202.161.10.95]) by mail.messagingengine.com (Postfix) with ESMTP id 192041482D; Thu, 30 Nov 2006 06:51:32 -0500 (EST) Message-ID: <456EC5C0.3010907@anu.edu.au> Date: Thu, 30 Nov 2006 11:51:00 -0000 From: John Pye User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Andrew STUBBS CC: Joel Brobecker , gdb@sourceware.org Subject: Re: usability: exiting from GDB References: <456A79B5.2020505@anu.edu.au> <456AFA30.80508@st.com> <456CFDF8.10408@anu.edu.au> <20061129050452.GK9968@adacore.com> <456D33C6.4050407@anu.edu.au> <20061129133748.GC28834@nevyn.them.org> <456E5704.8060102@anu.edu.au> <456EADC6.70403@st.com> In-Reply-To: <456EADC6.70403@st.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00247.txt.bz2 Hi Andrew Thanks for clarifying. Indeed you are right and the GDB behaviour does mirror the behaviour of other shells. I hadn't considered the case of stopped jobs, which I guess *is* analogous. So the only outcome from my issue was the missing newline when GDB exits. Thanks all for your comments and feedback. Cheers JP Andrew STUBBS wrote: > John Pye wrote: >> The ctrl-D behaviour is what I would prefer, certainly, and this would >> be more shell-like. But I don't like the confirmation question "Exit >> anyway?". > > It *is* precisely shell like. Try this: > > bash$ cat & > bash$ > > bash says: > > There are stopped jobs. > > [1]+ Stopped cat > >> The hook-quit thing does turn off the confirmation in the case of the >> "q" command, but *does not* work for the ctrl-D exit method. > > As advertised. > >> I guess the main thing is to get the ctrl-D functionality right. >> Presuming that others agree that this change would be desirable? > > I think everyone is agreed that the Ctrl-D behaviour is precisely the > same as that of bash and other shells, with the one exception that it > does not print a line break. > >> I find the ctrl-C behaviour unhelpful (ie suggesting I quit instead of >> asking me if I'd like to go ahead and do it) but it's not important >> really. > > The Ctrl-C behaviour is also only cosmetically different. It's hard to > see how to explain this any more clearly than has already been done, > but here goes. > > In both cases Ctrl-C interrupts the currently running command: > > bash$ cat > > bash$ > > (gdb) continue > Continuing. > > > Program received signal SIGINT, Interrupt. > 0xblahblah in ?? () > (gdb) > > In neither case does it quit the "shell". > > When you Ctrl-C a continue command it prints a message explaining > where the inferior program has stopped. > > When you Ctrl-C another GDB command it prints a message 'Quit' to tell > you that the command exited early, potentially. If no command was > running then the effect is *only* that you see this message. It is > *not* any sort of suggestion. If it did not print those four > characters, 'Quit', the behaviour would be exactly the same as bash. > > GDB could certainly improve it's Ctrl-C handling - there a many > commands that just can't be interrupted - and perhaps the aesthetics > could also be improved, but in principle it is exactly the same as > that used by bash. > > Hope that explains it for you > > Andrew