We all know Control-C traps the debugger. Sometimes you want an application to exit on Control-C instead of starting the debugger. You can do that using on_signal/3, as also used by library(main) for main/0.
I’ve noticed that ctest for running the test suite, when interrupted, leaves a lot of Prolog processes behind. That is because ctest seems to pass on the interrupt but doesn’t wait for the child. I think that is a bug of ctest (raised), but still this is probably not what we want.
The question is, when should we disable interrupt handling? There is a command line option --debug[=bool], which currently suppresses debug info and which we could also use to disable handling interrupts as why would you want to debug if you have suppressed debug info?. There is --signals=[bool], but that does too much as it also party inhibits asynchronous thread communication.
We could add one more flag, or is is --no-debug just right?
We could disable by default if not all I/O streams connect to a terminal (as is also done for disabling color output)?
Enable debugging by default on Ctrl-C only if we are running an interactive session (e.g. with top-level); this is better than simply all I/O streams being connected to the terminal.
Note: This is especially true for prolog command-line utilities that interact with the end-user (not the developer) through the terminal: like menu based utilities or prompt/reply interaction with the user. These ones would most likely use color, and you wouldn’t want the debugger to start if the user pressed Ctrl-C.
Provide a flag --debug-on-interrupt for the more rare cases when we want the debugger to start when a program is interrupted.
This is based on the fact that most unix programs don’t start the debugger on Ctrl-C but they terminate the program.
It also contributes to a good end-user experience since by default prolog command-line programs will behave like any other program.
Thanks! This was exactly what I was looking for. Implemented. Also added a Prolog flag debug_on_interrupt with the obvious meaning. The flag can be switched at runtime.
These seem good defaults while they allow for changing.
I don’t cease to be amazed at the speed with which you come out with features, better user experience, and a better prolog. This is probably the number one cause that SWI-Prolog is the most popular prolog.
Whenever I think of a feature I need or a use case I am trying to implement, I often think: “This probably was implemented already by Jan in some place that I have not looked at yet”…then I start digging and often I find it
