SQLite Forum

CTRL-C behavior in shell
Login

CTRL-C behavior in shell

(1) By anonymous on 2021-03-04 15:01:39 [source]

When CTRL-C is pressed during query execution, the query stops, 'Interrupt' is printed, and I'm back to the SQLite3 prompt. Good so far.

The problem is sometimes CTRL-C is pressed right at the moment the query ends naturally. At that point CTRL-C is interpreted as exit from SQLite3 shell.

This is impractical. One example is if you're using an in-memory database (for testing), you lose everything you've worked so far.

Could it be made that CTRL-C either never exits the shell (CTRL-D/Z can be used for that), or that a confirmation message is issued with default action to stay in the shell?

(2) By Stephan Beal (stephan) on 2021-03-04 15:52:36 in reply to 1 [link] [source]

The problem is sometimes CTRL-C is pressed right at the moment the query ends naturally. At that point CTRL-C is interpreted as exit from SQLite3 shell.

On my box (Linux on a Raspberry Pi 4b) it only does so if ctrl-c is pressed 3 times in a row with no other intervening keystrokes:

$ sqlite3
SQLite version 3.34.0 2020-11-24 13:14:15
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> ^C
sqlite> ^C
sqlite> ^C
sqlite> ^C^C
sqlite> ^C^C^C

Which implies that either you're tapping it too often or this is a platform-/build-option-specific problem (and you didn't mention your platform).

(3) By Larry Brasfield (larrybr) on 2021-03-04 18:00:38 in reply to 2 [link] [source]

It works as you say, Stephan, on Linux (and any other *Nix platform, I imagine.)

On Windows, a single ^C end the shell session abruptly. I agree with the OP that the mis-timed ^C susceptibility is worth a cure. It cannot be hard.

(4.1) By Larry Brasfield (larrybr) on 2023-04-19 00:11:28 edited from 4.0 in reply to 3 [link] [source]

I am glad to report that this annoyance is gone with this recent trunk check-in.

The fix was relatively easy. Figuring out what was going awry not so much. A debugger was practically useless for the task because the cause was the time relation between a pair of threads, something that a debugger is poor at revealing.

It would be good to get reports of any problems with this before the next 3.42.x release. Before then, behavior modification suggestions are welcome too.

(Behavior change appended via edit:)

The behavior is different now in several respects:

  1. When the CLI is not interactive, a single ^C kills it (as before) but an extra message is emitted to stderr. (This is not worth special-casing.)

  2. When the CLI is interactive and running a query, the first ^C interrupts its execution and returns control to the REPL. A second ^C ends the program.

  3. When the CLI is interactive and awaiting console input, two ^C inputs are required instead of one as before. This could be called "a bug", but I am calling it the "accidental ^C protection" feature. It is not worth special casing, particularly since there is little user-visible difference between a ^C that comes in near the end of executing something and a ^C hit at the prompt.

  4. It is no longer necessary to hit ^C three times. Twice suffices. (And anybody who loves hitting ^C can do so at the OS shell prompt after the CLI exits.)

  5. The behavior is the same for *Nix and Windows systems.1


  1. ^ The ^C response was subtly different between *Nix and Windows before, leading some to think this was an OS issue. It was, but only in the exact timing of the "interrupt" thread compared to the CLI's single "main" thread. The timing difference was amplified by the code's sensitivity to it.

(5) By Florian Balmer (florian.balmer) on 2023-04-19 07:31:59 in reply to 4.1 [link] [source]

... CTRL-D/Z ...

Just adding a note that this is now easy to do on Windows:

The last parameter to ReadConsoleW() can contain a mask of control keys to interrupt read mode and allow the caller to react, for example with auto-completion, clear screen (Ctrl+L) and exit (Ctrl+D).

And contrary to what the MSDN docs say, this feature already works on Windows XP.

(8) By Larry Brasfield (larrybr) on 2023-04-19 11:05:39 in reply to 5 [link] [source]

That's an interesting fact, but I do not see the relevance to how the CLI responds to control-C.

(9) By Florian Balmer (florian.balmer) on 2023-04-19 13:13:06 in reply to 8 [link] [source]

The OP mentioned Ctrl+D / Ctrl+Z, which are not handled by the terminal on Windows but need to be processed by the apps themselves.

(6.1) Originally by Florian Balmer (florian.balmer) with edits by Larry Brasfield (larrybr) on 2023-04-19 11:03:49 from 6.0 in reply to 4.1 [link] [source]

Deleted

(7.1) Originally by Florian Balmer (florian.balmer) with edits by Larry Brasfield (larrybr) on 2023-04-19 11:04:13 from 7.0 in reply to 6.0 [link] [source]

Deleted