thank you very much. I read the paragraph below several times. Unfortunately
the behavior of readline is somewhat different. The problem seemed to be that
signal handling is "too transparent" in that it ignores settings made in the signal
handler.
But I am on the way towards a solution. The first ingredient was Blakes recommendation
to bind ^C. That was correct, except that it didn't work. It worked for ^A, ^B, etc but
not for ^C. The missing piece was to entirely hide ^C's special role from readline
before calling readline(). After that ^C could be bound like any other ^something.
I am currently running a number of tests with this and I am hoping that I can commit
the solution tomorrow. That should include your ^C comments and also Blake's printout
issues.
/// Jürgen
On 07/22/2014 08:03 PM, David Lamkins wrote:
If you don't get to this today, I may have some time tonight to experiment with case (2).I'd start with (2). The thought of setjmp()/longjmp() in a C++ program makes me itch... ;)2. Look for a readline hook that gets called after the reinitialization that's supposedly done after return from the signal handler. Consider rl_startup_hook and rl_pre_input_hook. The idea is that the hook function would test the value of attention_raised (and interrupt_raised) and set rl_done.1. Build some additional scaffolding using setjmp() and longjmp(). The idea is that a longjmp() from the handler would return *after* the readline() call. Note the need to call rl_cleanup_after_signal() in this case.I can envision a couple ways to deal with this:That's my best working hyphothesis at this point.The real problem seems to be that readline() isn't seeing rl_done. In the context of the above-quoted paragraph, though, this may be explained by: " If and when the calling application's signal handler returns, Readline will reinitialize the terminal and continue to accept input". My best guess is that the reinitialization also affects other state in readline and clobbers the signal handler's having set rl_done.I believe that it's a mistake (or at best, needless) to call rl_delete_text() from Input::got_control_C(), but that's not the crux of the problem.The way I read this, readline() should be transparent w.r.t. ^C. Readline resignals your app, then resets *itself* when control returns from your app's signal handler.J'uergen,I noticed this paragraph in the readline documentation:
" Readline contains an internal signal handler that is installed for a
number of signals (`SIGINT', `SIGQUIT', `SIGTERM', `SIGALRM',
`SIGTSTP', `SIGTTIN', and `SIGTTOU'). When one of these signals is
received, the signal handler will reset the terminal attributes to
those that were in effect before `readline()' was called, reset the
signal handling to what it was before `readline()' was called, and
resend the signal to the calling application. If and when the calling
application's signal handler returns, Readline will reinitialize the
terminal and continue to accept input. When a `SIGINT' is received,
the Readline signal handler performs some additional work, which will
cause any partially-entered line to be aborted (see the description of
`rl_free_line_state()' below)."
On Tue, Jul 22, 2014 at 7:36 AM, Juergen Sauermann <address@hidden> wrote:
Hi Blake,
I tried, but it did not work.
The deeper I go into readline the more weird it gets.
If I do nothing then I get the first ^C delivered as signal but not subsequent ones.
I would have preferred if two ^Cs (i.e. INTERRUPT rather than ATTENTION) would
stop printouts, but readline delivers only one.
I also tried binding to ^C; interestingly I can bind to any other key except ^C. The
bind to ^C succeeds (returns no error) but the function bound to it is not
called. For other keys this works.
/// Jürgen
On 07/21/2014 08:12 PM, Blake McBride wrote:
Does this help?
This may be related to the cooked/uncooked/rare terminal modes;
^Cdoes not always send a signal. It seems likely that readline uncooks the terminal, and thus any signals caused by keyboard input must be due to logic within readline itself; it seems plausible that it might only trigger a SIGINT on two sequential^Cs (especially since for many programs that utilise readline such as shells and REPLs, the program exiting on a single^Cwould be very annoying!).You might be able to change this behaviour by using the readline API to rebind
^Cto some of your own code that triggers a SIGINT. I haven't used readline from Haskell, just from C, so I'm not sure exactly how you'd go about this, but the binding seems rich enough to achieve it.
--
"Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-eight million miles is an utterly insignificant little blue-green planet whose ape-descended life forms are so amazingly primitive that they still think programming in Java is a pretty neat idea."
-- With apologies to Douglas Adams, who I like to think would have appreciated this.
http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/