This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [RFC] Don't propagate our current terminal state to the inferior
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 23 Nov 2014 14:24:56 +0400
- Subject: Re: [PATCH] [RFC] Don't propagate our current terminal state to the inferior
- Authentication-results: sourceware.org; auth=none
- References: <1416688748-20448-1-git-send-email-patrick at parcs dot ath dot cx>
> Currently when we start an inferior we have the inferior inherit our
> terminal state. Under TUI, our terminal is highly modified by ncurses
> and readline. So when starting an inferior under TUI, the inferior will
> have a highly modified terminal state which will interfere with standard
> I/O. For example,
>
> $ gdb gdb
> (gdb) break main
> (gdb) run
> (gdb) print puts ("a\nb")
> a
> b
> $1 = 4
> (gdb) [enter TUI mode]
> (gdb) run
> (gdb) [exit TUI mode]
> (gdb) print puts ("a\nb")
> a
> b
> $2 = 4
> (gdb) print puts ("a\r\nb\r")
> a
> b
> $3 = 6
>
> As you can see, when we start the inferior under the regular interface,
> puts() prints the text properly. But when we start the inferior under
> TUI, puts() does not print the text properly. This is because when we
> start the inferior under TUI it inherits our current terminal state
> which has been modified by ncurses to, among other things, require an
> explicit \r\n to print a new line. As a result the inferior performs
> standard I/O in an unexpected way.
>
> Because of this discrepancy, it doesn't seem like a good idea to have
> the inferior inherit our _current_ terminal state for it may have been
> modified by readline and/or ncurses. Instead, we should have the
> inferior inherit a pristine snapshot of our terminal state taken before
> readline or ncurses have had a chance to alter it. This enables the
> inferior to run in a more accurate way, more closely mimicking its
> behavior had the program run standalone. And it fixes the above
> mentioned issue.
>
> I wonder, does this change make sense? What do others think?
FWIW: It does make sense to me, but I have been known to have a really
superficial view or how terminals work. I'd be more comfortable if you
waited for someone like Pedro to give it a second look. If no one
reviews it by, say, Dec 8th, can you ping me again?
Thank you,
--
Joel