On Thu, Jul 21, 2016 at 12:24:57PM -0400, Chet Ramey wrote: > On 7/19/16 6:42 PM, frede...@ofb.net wrote: > > Thanks Chet. I know Python and R have a similar model. I think the > > question is not whether it is OK for Readline to take over the > > application's signal handling, but whether it was OK for Readline to > > catch signals and then forward them to the application - as it was > > doing before 6.3. > > Sigh. This is a different question. Readline still does this, as it > always has.
It seems we're rehashing old conversations. I think the change that you made in 6.3, which I am referring to, was to make Readline no longer catch signals outside of rl_callback_read_char(), thus requiring application programmers to re-implement Readline's signal handlers. I understand that forwarding is still done for signals received within this function. > It was not OK to do cleanup and other processing in a signal > handler, so Readline does this now from a function that is not > called in a signal handling context. Yes, there is RL_CHECK_SIGNALS which is not exposed to the application. That's why I proposed exposing a function which does the same thing in my original message about this: https://lists.gnu.org/archive/html/bug-readline/2016-04/msg00066.html This would require all callback interface consumers to make a pre-approved 1-line change to their code, not ideal but better than 10 lines IMHO. Frederick _______________________________________________ Bug-readline mailing list Bug-readline@gnu.org https://lists.gnu.org/mailman/listinfo/bug-readline
