I'm running R 3.2.2 (2015-08-14) under Arch Linux. I've noticed a problem with the command line interface in R for a few years. The problem is that when enter a "backward incremental search" mode by pressing Control-R, and then exit the mode using Control-C, the behavior of R is unexpected and counterintuitive. First of all, one notices when entering "Ctrl-R some-text Ctrl-C Return" that even though the command line appeared to be empty after Ctrl-C, upon pressing Return it mysteriously fills up with the last command that was encountered by isearch, and then executes that command. This happens no matter how many times I press Ctrl-C. Also, when I do "Ctrl-R some-text Ctrl-C Ctrl-R", it seems that "some-text" is already being searched for. I haven't looked at the code, but perhaps R needs to somehow clear the input buffer when the user presses Ctrl-C? I think it would be most intuitive if Ctrl-C had the same effect as Ctrl-G in isearch mode. Certainly, it seems undesirable to have an invisible command being executed when the user presses "Return". Thank you for a (otherwise) great piece of software!
Came here to mention the same oddity -- either exit i-search and show the prompt on Ctrl-C or do neither. Exiting i-search properly would match bash's behaviour for example, which is the main reason I often try to exit i-search this way then end up accidentally running some recent command or another.
However, the question of what exactly Readline or the client application should do when a SIGINT arrives is somewhat fuzzy, and there appears to be no Readline function to just cancel the line entry and clean up state to get the same behavior as Bash (which uses the basic 'readline()' interface) in Readline callback interface applications like R or Python. I gather from Chet Ramey that our SIGINT handler should do something like this: rl_free_line_state (); rl_cleanup_after_signal (); RL_UNSETSTATE(RL_STATE_ISEARCH|RL_STATE_NSEARCH|RL_STATE_VIMOTION|RL_STATE_NUMERICARG|RL_STATE_MULTIKEY); rl_done = 1; rl_line_buffer[rl_point = rl_end = rl_mark = 0] = 0; rl_callback_handler_remove (); printf("\n"); /* possibly exit the loop, call rl_callback_handler_install() etc. */ The Python team also calls a new Readline 7 function after rl_free_line_state: #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0700 rl_callback_sigcleanup(); #endif See https://bugs.python.org/file40054/readline-sigcleanup.patch None of this really makes sense to me, I'd really prefer that Readline's signal handlers should be installed during our 'select()' loop, as they were in Readline <= 6.2, and that the Readline SIGINT handler should take care of noting that the user cancelled a line entry, as I think is done for the basic "readline()" interface (haven't checked). The first issue, which is that Readline 6.3 stopped handling signals outside of the library itself, also caused us to not be able to resize terminals running the R CLI: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16604 Things have apparently been broken for several years at least, in both R and Python. Even applications using Readline 5 seem to show the isearch-SIGINT bug. There is a related thread on Stackoverflow: http://stackoverflow.com/questions/16828378/readline-get-a-new-prompt-on-sigint However, I think the answers there are wrong.
me> as I think is done for the basic "readline()" interface (haven't checked). Actually, I just noticed that the Stackoverflow question is about the basic "readline()" interface, and the poster is saying that the input line is not in fact cleared on ^C.
Created attachment 2070 [details] fix for isearch-sigint bug, applies to R-devel I'm not very familiar with R's source code but I tried to come up with the most reasonable possible workaround for this bug, under the circumstances. Let me know what needs to be changed before it can be accepted. Thanks.
I think this is fixed by Martin Maechler in the current R SVN, should I close it? (same with bug 16604)
The reason it is not closed, is that the fix is only for *some* platforms: those with a new readline. E.g., the Mac version of R does not have that.. (for licence reasons) and so the bug is not fixed for R on the mac, AFAIK.