Shell duplicate prompt in version 3.49

(1.1) By neo_in_matrix on 2025-06-07 11:08:03 edited from 1.0 [source]

I think starting from version 3.49, I always get duplicate shell prompt like below:

C:\TEMP>sqlite3
SQLite version 3.49.2 2025-05-07 10:39:52
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .h
Usage: .headers on|off
sqlite> sqlite> select 1234;
1234
sqlite> sqlite>

(2) By Stephan Beal (stephan) on 2025-06-07 10:00:35 in reply to 1.0 [link] [source]

I think starting from version 3.49, I always get douplicate shell prompt like below:

Is this a cross-compiled binary? All of the reports we've received of that problem came from cross-compiled builds on Windows, a build mode we do not actively support because of its tendency to exhibit weird behaviors like that one.

To the best of my fallible knowledge we have never received a report of this on a non-cross-compiled Windows binary (and have only ever heard of it happening on Windows).

If yours is not cross-compiled, then your report is an exception to the rule and we'll need more info about how you obtained or built it. We also need to know which Windows version you are running, as well as which shell/terminal app you are using.

(3.2) By neo_in_matrix on 2025-06-07 11:07:37 edited from 3.1 in reply to 2 [link] [source]

I forgot to mention that I usually build sqlite3.exe binary from the amalgamation source, using gcc from MinGW/msys2. This pratice has been performed for years.

The package sqlite3 that is provided by msys2 itself also demonstrates a strange behavior when I run sqlite3 in its Terminal window - sqlite3 runs but shows no prompt.

I also tried building sqlite3.exe using MSVC 2005/2008/2013, but get same problem with the prompt.

However, the result sqlite3.exe built with MSVC 2022 behaves correctly as before.

I have a one-liner fix for this problem:

In local_getline function, line 1347 adding a condition:
if (zLine[0]) break;

I don't know why the sqlite3_fgets function still returns "\n" after last successful read.

(4) By Stephan Beal (stephan) on 2025-06-07 11:12:38 in reply to 3.1 [link] [source]

I forgot to menstion that I usually build sqlite3.exe binary from the amalgamation source, using gcc from MinGW/msys2. This pratice has been performed for years.

The console output for Windows has been considerably reworked in the past year or so, in close cooperation with a third party which specializes in, and exclusively uses, Windows. Their assessment is that the current sqlite API behaviors, and their internal usage of Windows APIs, are correct, suggesting that this quirk is caused by an msys-specific incompatibility, as opposed to an sqlite-level Windows API misuse.

I also tried building sqlite3.exe using MSVC 2005/2008/2013,

We don't actively support any of those. If they work for you, great, but if not...

However, the result sqlite3.exe built with MSVC 2022 behaves correctly as before.

2022 is the most recent one we actively pursue fixes for.

I don't know why the sqlite3_fgets function still returns "n" after last successful read.

Neither do we, but if you figure it out we would love to hear about it.

(5.1) By neo_in_matrix on 2025-06-08 03:53:50 edited from 5.0 in reply to 4 [link] [source]

After about 30 minutes of digging, I found out that on Windows, you have to #define SQLITE_USE_W32_FOR_CONSOLE_IO; now everything works.

BTW, it's a surprise that you devs of SQLITE do not know this macro in sqlite3_fgets.

EDIT:
in sqlite3_fgets:
    /* When reading from the command-prompt in Windows, it is necessary
    ** to use _O_WTEXT input mode to read UTF-16 characters, then translate
    ** that into UTF-8.  Otherwise, non-ASCII characters all get translated
    ** into '?'.
    */
_setmode(_fileno(in), IsConsole(in) ? _O_WTEXT : _O_U8TEXT);

My tests show just the opposite. Setting _O_WTEXT mode causes the phantom read of "\n" even after a successful read.

My test code:
WCHAR sz[100] = {'A'};
//_setmode(_fileno(stdin), _O_WTEXT);
perror(0);
fgetws(sz, 10, stdin);
_putws(sz);
perror(0);
fgetws(sz, 10, stdin);
_putws(sz);

When I type in Chinese text, _putws correctly outputs input text.

(6) By Florian Balmer (florian.balmer) on 2025-06-08 04:32:00 in reply to 5.1 [link] [source]

I had to apply the same fix to my custom Fossil build, i.e. add SQLITE_USE_W32_FOR_CONSOLE_IO to the build flags for the SQLite shell to fix the double prompts in the built-in fossil sql command shell.

I'm using MSVC 15.00 (WDK7) and MSVC 19.44.35209 (from Visual Studio 2022) to build Fossil, and they both had the double prompts. The official Fossil 2.26 release is built with MSVC 19.42.34436 (somewhat earlier Visual Studio 2022) without the SQLITE_USE_W32_FOR_CONSOLE_IO flag, but doesn't have the double prompts. Strange, somehow, because an intermediary MSVC 19.42 change that happens to fix the problem seems unlikely.