I'm posting this in case anybody else has seen the same and knows how or why it happens.

For a few years, I have regularly used various builds of the SQLite CLI on *Nix systems, including images taken from the download page for a few Linux systems. I am fond of using job control to suspend execution of command-line utilities, including the CLI, normally effected with control-Z.

To my great surprise, after putting the recently downloaded version 3.40.1 CLI into ~/bin, and running it, I find that control-Z no longer suspends its execution. Instead, the line reader echoes "�" in place of the usual "^Z" and keeps going, complaining about that "�" if it's not backed off.

The CLI built from the same source, using plain "./configure", acts like all the other builds except this recalcitrant one with respect to suspension (aka "Stopping") via the keyboard. The unstoppable one shows most of the same compile options, excepting this list of deltas (+ for unstoppable, - for normal), none of which should have such an effect: +COMPILER=gcc-5.2.0 -COMPILER=gcc-11.3.0 +ENABLE_FTS5 +ENABLE_GEOPOLY +ENABLE_PREUPDATE_HOOK -HAVE_ISNAN +MUTEX_OMIT -MUTEX_PTHREADS +THREADSAFE=0 -THREADSAFE=1 .

The most significant difference, I suspected, is that the downloaded CLI is a 32-bit executable while the ones which I usually use are locally built as 64-bit executables. But when I build the 32-bit CLI locally¹, it is able to be stopped normally via control-Z.

Is anybody else seeing this behavior? Is it something strange about my fairly stock Xubuntu setup? Or is the project-distributed sqlite3 somehow to blame?

1. ^{^} The file utility says: "ELF 32-bit LSB pie executable, Intel 80386 ..."

On Windows CTRL-Z is end-of-file (CTRL-D on Linux machines).

Is it possible that one of the builds is "cooking" the stdin stream (aka readline or equivalent) while the other is not?

I have not tried the 32-bit Linux-targetted CLI on WSL, yet.¹ That might be a useful datapoint, although I am unsure what could be made of either result.

I know the CLI's "explicit" treatment of its I/O streams pretty well, which is no treatment in the way of "cooking" or "going raw" (in the stty sense.) But maybe the distributed images have been built with a strange readline equivalent that does some such machination. (That would be a shame because it is normally not necessary to mess with stdin settings to make line editing work for interactive scenarios. Forcing the buffering mode would be the most that a line-collect-edit library should have to do unless it means to do things in 2-D, which would be way beyond its charter IMO.)

Do you see the control-Z resistance on either a genuine Linux system or WSL?

1. ^{^} The annoying behavior I report in post #1 is exhibited by the ELF 32-bit i836 image for Linux taken from the project download page.

I don't use WSL. The only Linux I have access to (at the moment) is a VM running CentOS Stream. configuring the build with --disable-readline --disable-ncurses or the default (equivalent to --enable-readline --enable-ncurses) job control works (this is x64 -- I do not have x86 libraries installed).

The above and your later experiments are quite helpful. I am running the same Xubuntu release, so your results tell me that this issue is unlikely to be that I have somehow got this system configured in an arcanely weird way.¹

My rebuild from the source tagged as 3.40.1, with CFLAGS=-m32, does not exhibit the odd handling of ^Z. So I will examine your other results with an eye toward understanding what it takes to get ^Z-choking behavior.

1. ^{^} Or, it's a weird configuration pitfall but one somebody else has fallen into.

(Updated twice to reflect new data.)

If I understand your results correctly, you have not replicated the not-stopped-by-control-Z behavior with your own builds, but see it with the build taken from the download page.

I have downloaded builds going back to version 3.38.0, all of which evince the same swallowing (and choking upon) control-Z behavior.

My conclusion is that this is due to something special about the particular machine on which those builds are done. I doubt it is the (7+ years) old compiler, but its age makes me suspect that the linked-in line editing library is responsible. I will take this up with the builder.

Thanks for helping get this sorted.

(Added for 11.1:)

I have found that a running, control-Z-swallowing sqlite3 session can be made compliant to stop requests thusly: stty -F <terminal_device> isig , where "<terminal_device>" is whatever the tty utility says it is for the terminal running that session.¹ I think this shows that the stop-resistant CLI is doctoring tty settings somehow.

(Added for 11.2:)

Reading code in the linenoise "library", I see that this is exactly what is happening. The downloadable CLI must be built with that line editing package. This also explains why control-C puts an immediate end to that CLI's processing rather than (perhaps) interrupting a long query and having to be repeated twice more to end the process.

I believe this resolves the mystery part of this puzzle. I've become spoiled by the more sophisticated readline and equivalents.

1. ^{^} I have yet to figure out how to get this stty call done in the background by something started concurrently with the sqlite3 CLI.

I also came across linenoise while investigating this, and specifically this bug report:

https://github.com/antirez/linenoise/issues/141

It's reported fixed in Jan 2018, so if the build environment is 7 years old then simply updating linenoise may be sufficient.

That's a great tip. My reading of linenoise.c was directly from the author's GitHub page, so it appears that the fix report is more of a "there is a simple way to fix this" report. But it is an easy and obvious fix.

Thanks.