Re: winch trap delayed until keypress

[Chet Ramey]

On 5/22/14, 10:19 PM, Linda Walsh wrote:

>> We're mostly talking about the
>> interaction between readline and the applications that use it. 
> ----
>     I'm not sure I see the problem there -- since the application
> runs "after bash" (i.e. bash forks&execs it, then waits for it to return
> in the normal foreground case), wouldn't the application be able to
> install whatever signal handling it wants and possibly interfere w/bash
> getting the signal, vs. bash causing app interferences?

I think you misunderstand.  Applications, in this context, are those
programs that link with readline and use it for command line editing.
Bash is an application from readline's perspective.  Readline has to
manage its signal handling in a way that doesn't preclude an application
that links with it from doing what it needs.

>> While
>> you can use readline in a script -- and there is a pending bug with
>> readline and timeouts in scripts when called by the read builtin -- it's
>> not the primary use case.  And SIGWINCH is the only signal subject to
>> this problem.
> ---
> 
> Wait.. there is a pending bug w/readline and timeouts, (i.e. SIGALARM?) and
> SIGWINCH is the only one -- is the bug w/readline & timeouts, or only
> in the presence of SIGWINCH?  

It has to do with the read builtin not setting the right hook for readline
and readline not doing what it needs to with SIGALRM.  It's not anything
related to the framework or approach, and unconnected to any SIGWINCH
issues except that they are both signals.

I've attached the sample patch so you can see what I'm talking about.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

read-readline-timeout.patch
Description: Text Data