Re: usability: exiting from GDB

[Andrew STUBBS <andrew.stubbs@st.com>]

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$ <Ctrl-D>

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
<Ctrl-C>
bash$

(gdb) continue
Continuing.
<Ctrl-C>

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