Re: [Bug-readline] Forwarding input from ncurses to readline

[Ulf Magnusson]

On Sat, Feb 21, 2015 at 5:56 PM, Chet Ramey <address@hidden> 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