Patch release 3.44.1 will probably come out tomorrow (2023-11-22). Details can be previewed at https://sqlite.org/draft/releaselog/3_44_1.html. A pre-release snapshot is available on the Download page. A complete timeline of changes can be seen at https://sqlite.org/src/timeline?tl=branch-3.44,version-3.44.0, or with more context at https://sqlite.org/src/timeline?p=branch-3.44&bt=version-3.44.0.

Your review and testing of this proposed patch release is appreciated. Please report any issues as follow-ups to this forum post, or directly to me at drh at sqlite dot org.

Hi.

Can I assume the fixes applied to 3.44.1 are also on the trunk of 3.45.0?

The console I/O change on branch-3.44 (to become 3.44.1 patch release) will soon be merged to trunk. It's not there yet. has been merged to trunk.

Thanks, Larry. I'll wait for the push of it to trunk.

Thanks.

Should the -no-utf8 flag be removed now when the console uses utf-16?

Still seems to be there in draft version:

https://sqlite.org/draft/cli.html

Should the -no-utf8 flag be removed now when the console uses utf-16?

Perhaps. Or it might be mentioned for awhile for those users still using 3.44.0 . Something will change.

I'm the coworker mentioned by Len in the previous message. On further checks, it turns out that the SQLite 3-44-1 shell in PowerShell also has a broken .output command. I hadn't noticed that I was accidentally running an earlier version, which worked correctly.

I've now also tried the macOS version of the 3-44-1 shell available from the SQLite download page, and the same problem happens there: .output test.sql followed by .dump produces a zero byte file and the dump output goes to the console.

.output works as expected in the 3-44-0 shell on every platform I've tried (cmd.exe and powershell.exe on Windows 10 x64, Terminal with zsh in macOS Sonoma).

Based on my testing so far this looks like a general problem with .output and .once in the SQLite 3-44-1 shell.

multi-line sql statement sometimes cannot be executed. such as

create table course
(
     c_id int not null,
     cname varchar(50),
     note varchar(500) ,
     primary key (c_id)
);

It shows

sqlite> create table course
   ...> (
(x1...>      c_id int not null,
(x1...>      cname varchar(50),
(x1...>      note varchar(500) ,
(x1...>      primary key (c_id)
(x1...> );

(x1...>

but in sqlite 3.43, it works fine

SQLite version 3.43.0 2023-08-24 12:36:59
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table course
   ...> (
(x1...>      c_id int not null,
(x1...>      cname varchar(50),
(x1...>      note varchar(500) ,
(x1...>      primary key (c_id)
(x1...> );
sqlite>

Thanks Len and David for your clear reports. This bug, which affects the CLI for all platforms, has been fixed.

I expect this will result in another patch release.

I have been unable to reproduce the behavior you report.

Could you please say:

• what OS this is happening on;
  
• what the ".version" command emits;
  
• how often you see this odd behavior; and
  
• What was done prior to seeing it¹?

---

1. ^{^} A summary is fine; a whole session screen-scrape is better if short.

Pre-release snapshots of the CLI are available on the download page: https://sqlite.org/download.html

Please try them out and report back whether this fixes your problem.

Expect to see the 3.44.2 patch release tomorrow (2023-11-24) if there are no further issues.

I have been unable to reproduce the behavior you report.

Could you please say:

what OS this is happening on;windows 7 x64

what the ".version" command emits;SQLite 3.44.1 2023-11-22 14:18:12 d295f48e8f367b066b881780c98bdf980a1d550397d5ba0b0e49842c95b3e8b4 zlib version 1.3 msvc-1937 (64-bit)

how often you see this odd behavior; almost every time

What was done prior to seeing it? nothing

i put the screenshot here

one more thing, I use copy and paste the code above. and I tried to input the sql by hand, it works fine.

use -no-utf8 hasn't effect. see attachement

and copy and paste works fine in version 3.44 , use -no-utf8 see attachement2

I've repeated my test using the osx and win-x64 tools with the 3.44.2 pre-release version and the .output command is working correctly for me. Thanks.

I have had mixed results reproducing the reported behavior on Windows 7.

With cmd.exe, powershell.exe, or sqlite3.exe (v3.44.1) running in the default console, (as created by \Windows\System32\conhost.exe), pasting your "create table course (...);" statement works exactly as it should, resulting in a primary prompt and a created table. (I call this result "works" or "as one would like".)

With sqlite3.exe (v3.44.1) running in several alternative consoles, pasting either works or fails in various ways, depending on the source of the clipboard content. The alternative consoles I tried were "ConEmu 230724 (64) (Stable)" and "Take Command v14.02". I am still exploring what programs are able to set the clipboard content with tags that allow these alternative console hosts to recover the content as it appears during copy to the clipboard.

On Windows 10, the default console (conhost.exe), Windows Terminal, and the two alternative consoles just mentioned, all operate as one would like, pasting characters just as they appear in the source display where the clipboard content was copied.

As part of my investigation, on Windows 7, I also tried, in those various console hosts, an earlier development version of the CLI which had a build option to use a modified form of the legacy CLI translation between its internal UTF-8 and what the console is taking as MBCS. This version appears to work fairly well for your ASCII example, although it has some known shortcomings¹ relative to the released version which does UTF-16 console I/O exclusively.

I'm not sure yet what the answer will be. The 3rd party console applications do strange things, most or all of which involve keeping a hidden conhost.exe process running and intercepting hosted application console API calls to process them into manipulations of that hidden conhost.exe process. These machinations evolved over time, and I hesitate to undertake a search for a single solution that interacts well with them all.

---

1. ^{^} The known shortcomings relate to console I/O of characters outside of the ASCII subset of Unicode.

(Tested under W7/64 in CMD and FAR)

I get that issue if I don't paste the very last CR+LF Larry.

Otherwise, it does work flawlessly.

[ On .timer output redirected per .output ]
Can we have the behaviour as per 3.44.

This will happen for the 3.45 release. It's on trunk now.

That's interesting. Do you mean cmd.exe in the Windows default console and FAR in its specialized console? Or do you mean cmd.exe running under the auspices of FAR?

I ask because on the Win7 system I'm using for testing, cmd.exe in the default console operates correctly with the 3.44.1 CLI whether the clipboard ends with a newline or not.

Do I mean cmd.exe in the Windows default console and FAR in its specialized console ? Yep.

(No typing, just cut&paste's)

w/o ending CR+LF:

R:\>sqlite3.exe
SQLite version 3.44.2 2023-11-24 11:41:44 (UTF-16 console I/O)
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table course
   ...> (
(x1...>      c_id int not null,
(x1...>      cname varchar(50),
(x1...>      note varchar(500) ,
(x1...>      primary key (c_id)
(x1...> );
_

I use the underscore character here above to illustrate where the blinking cursor actually is.

With the final CR+LF, all is fine:

R:\>sqlite3.exe
SQLite version 3.44.2 2023-11-24 11:41:44 (UTF-16 console I/O)
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table course
   ...> (
(x1...>      c_id int not null,
(x1...>      cname varchar(50),
(x1...>      note varchar(500) ,
(x1...>      primary key (c_id)
(x1...> );
sqlite> .tables
course
sqlite> .q

R:\>

Same behaviour with CP 850 or CP 65001, CMD or FAR console.

Fixing issues without being able to reproduce them is hard.

Don't hesitate to submit any other test which could help you Larry.

Fixing issues without being able to reproduce them is hard.

Yes. Fortunately, I am able to reproduce your observation with the stock console running cmd.exe, whereby the line-ending makes a big difference. This gives me a thread to pull on, and some experiments to run.

Don't hesitate to submit any other test which could help you Larry.

Thanks. Once I sort out what is happening with the stock shell on the stock console, I will happily ask for a test with FAR running by itself. An odd aspect of this misbehavior is how it varies among console hosts.

duckdb has similar issue