[patch] Dummy first call to gdb_has_a_terminal()

[Balazs Kezes <rlblaster@gmail.com>]

Hi,

I've noticed a weird behaviour with TUI at home and at work. It appears when I
switch to the other mode (to command line from gdbtui or to tui from gdb). It
does fix itself when I manage to switch back, but sometimes after executing a
command it messes up readline so I can't switch back easily.

For example:

gdbtui /bin/echo
^x^a
run

The input is messed up now on my computer.

I think bug gdb/9294 is exactly this.

I've tracked it down to gdb_has_a_terminal().  Deep in tui_enable() this
function this called. At this time the terminal has a messed up state (for
example echo is disabled) which is fine. But it turns out this is the first
call to this function and therefore it saves the current terminal settings
which will be used to restore the terminal before displaying the prompt after
executing a command. Even though it works for the current mode, it doesn't
for the other. A neutral mode (the state when gdb starts up) seems to work for
both modes.

The fix is to have a dummy first call somewhere where the terminal is still in
sane state.

Cheers,
Balazs

Index: tui-interp.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui-interp.c,v
retrieving revision 1.27
diff -c -p -r1.27 tui-interp.c
*** tui-interp.c	17 May 2010 22:21:43 -0000	1.27
--- tui-interp.c	18 Jul 2010 00:29:25 -0000
*************** _initialize_tui_interp (void)
*** 224,229 ****
--- 224,232 ----
      tui_command_loop,
    };

+   /* Dummy first call to save sane terminal settings. */
+   (void) gdb_has_a_terminal ();
+
    /* Create a default uiout builder for the TUI.  */
    tui_out = tui_out_new (gdb_stdout);
    interp_add (interp_new (INTERP_TUI, NULL, tui_out, &procs));