On Sat, Feb 21, 2015 at 5:56 PM, Chet Ramey <[email protected]> wrote: > On 2/20/15 8:01 PM, Ulf Magnusson wrote: > >>> Pressing enter a few times and resizing the terminal in between shows >>> that LINES and COLUMNS never change. The select() is important here as >>> the program blocks inside rl_callback_read_char() otherwise, which >>> hides the issue. >>> >>> /Ulf >> >> This comment makes it look like it's intentional: >> >> "Signal handlers are only installed when the application calls back >> into readline, so readline doesn't `steal' signals from the >> application." >> >> That seems to make letting readline deal with signals much less useful >> for the alternate interface though. Maybe the manual could clarify >> that you need to e.g. unprep the terminal yourself if a signal if a >> signal arrives between two rl_callback_read_char() calls. > > It is intentional. Consider the typical use case for the callback mode: > an application does whatever it does until it detects that input is > available, at which point it calls readline to read it. If readline had > signal handlers installed the whole time, a SIGINT arriving while the > application had control would not be handled until the next keypress > that caused the application to call readline_callback_read_char(). That > could be a very long time.
Ah, yeah, that makes sense. I forgot that the actual handling is deferred when using the alternate interface too. Thanks for the explanation. Do you think it would be a good idea to add something like the following to the documentation for rl_callback_read_char()? "readline will install signal handlers (if rl_catch_signals or rl_catch_sigwinch is 1) only for the duration of the rl_callback_read_char() call. Applications that use the alternate interface must take care to handle signals that arrive between calls to rl_callback_read_char() and call e.g. rl_deprep_terminal() as appropriate." The rl_callback_handler_install() documentation could be extended with the following as well: "The handler function receives the text of the line as an argument; it should free() the line when it has finished with it." I missed that the user code is responsible for free()ing the line at first, and so did http://r.789695.n4.nabble.com/memory-leak-in-readline-code-td920731.html. /Ulf _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
