From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas_Karagas@cirilium.com To: Keith Seitz Cc: insight@sourceware.cygnus.com Subject: Re: prompt in console window Date: Thu, 15 Jun 2000 10:11:00 -0000 Message-id: X-SW-Source: 2000-q2/msg00274.html >> >> Hello, Insight gurus... >> >> I've recently come across a problem using the console window in Insight. >> In ordinary GDB, if the number of lines printed exceeds the 'height' >> parameter, then the debugger will issue the prompt '---Type to >> continue, or q to quit---'. However, this apparently doesn't work >> in the Insight console, as the call to readline (readline.c:337) from >> prompt_for_continue (utils.c:1619) always returns 0x0, and never shows the >> prompt in the console window. I imagine that this is because readline >> expects everything to be going to and from stdout (since it doesn't require >> a stream as a parameter). Is there a quick fix for this that doesn't >> involve fiddling with readline, and therefore binutils (I think that's >> where it lives)? Thanks in advance. > >Ugh. Don't even ask. This is very nasty, and not particularly useful in >a GUI, anyway (IMO). That's why man invented scrollbars. O:-) > >The trick that Insight uses to turn this off is "set height 0", which >tells gdb that the window height is zero lines high. This can be >overridden by setting it to some number, but I just tried it in a recent >snapshot, and it did exactly what I thought it would: it works as >expected, but the message "---Type ..." appears in the >controlling terminal, not in the console window. (Which reminds me, why >haven't we closed stdout???) This happens because this message is passed >to readline to handle, and readline doesn't understand how to use the >GUI's printing streams. In order for anything to show up in the GUI, all >output MUST pass through fputs_unfiltered, which is hooked. This >function is called by all of gdb's printf_unfiltered/filtered commands. >(So if anyone happens to see a "printf" or "fprintf" or "putc" or "puts" >or anything like them without "_unfiltered" or "_filtered" in gdb, it's >a bug.) > >We could hack readline to take an input/output hook, but when we >upgraded to the lastest version of readline, we really wanted to avoid >any hacking. I suspect this could be done, but I've not taken a good, >serious look at readline. > >Of course, the console window could be modified to do this, too. It >probably wouldn't be too difficult, either, but it would not qualify as >"quick". Use ConsoleWin::insert to count the number of lines inserted, >when it hits some maximum, output the prompt, wait for the keypress, >etc. The trick, though, is that many internal messages/errors are sent >to the console. One must be certain that we are processing user input >when we do this (so set some flag saying it's okay to do this in >ConsoleWin::invoke). That part would be quick, but hooking it all up to >the preferences dialog and all the little nitpicks (adding online >documentation for it) can be too easily overlooked. > >Keith >-- >Why chat when you can Firetalk? >Firetalk ID: Keith (10320) >www.firetalk.com Hmm... perhaps I can ask an easier question. The only reason that I wanted to get the prompt_for_continue prompt back was that I wanted a way to stop a gdb macro (the kind that are defined in the .gdbinit file) that had started running, in case it was taking too long and I didn't care about the rest of the output. With the command-line gdb, you could type Ctrl-C at that prompt to stop whatever was running, including a macro. Would it be easier (and more helpful to the rest of the world) to get Ctrl-C working in the console window instead of the unnecessary prompt? Nicholas Karagas Associate Software Engineer Cirilium Corporation Tempe, AZ (480) 317-1144