Using the 32-bit CLI on Windows, when I paste in the CLI text/script that is longer than 4094 characters, it truncates at 4094 characters. Does this limit apply by design or am I doing something odd?

This is a limitation of the Windows Console input stream buffer.

The limitation used to be 255 characters. I suppose someone at Microsoft recently realized that Bill was wrong when he posited that 255 (256 with the zero terminator) should be enough for anyone.

But nobody will ever need more than 64 kilobytes of RAM, right? Or was it 56?

Aask, you're encountering a limit on the length of a particular line rather than a limit for a multi-line script, is that right?

FWIW, I just succeeded in pasting a script of 68,002 bytes at the CLI prompt.

Win 10, version 1809. Sqlite3.exe 3.39.4 as released, 32-bit version.

... you're encountering a limit on the length of a particular line ...

Yes. No issues with multi-line scripts.

I believe that Windows now has two different native shells. Try it in the other shell.

I can tell you that there's nothing in the SQLite source code that limits things to 4,096 characters (or 4,095, or anything like that).

Confirming Simon's assertion regarding CLI line-length limitation in two ways:

1. The following line, without any characters elided, can be pasted into the CLI¹ or interpreted by it via its .read command: /* #[8190 characters elided]# */ SELECT 'overly commented query'; , without any strangeness, misbehavior or complaint.

2. The CLI's code for reading input lines uses a dynamically allocated buffer which it grows as necessary to accommodate such ridiculous input.

There are limits, of course. Some length of such absurd input lines is going to produce an out-of-memory error when the CLI attempts to grow its line buffer. It would be boring and pointless to find where that limit is.

1. ^{^} Here, "can be pasted" means without hinderance from the platform. Some platforms, notably those named after certain building openings, impose pasting length limits at their stock console.

Actually, the limitation is not the "console application". It is the internal Windows input line buffer and is quite independent of the application that is attached to the "spigot end" of the Windows input queue. It also applies to "pasted input" into a hooey-gooey field as well. The limitation is at a lower level than the "application". It is an inherent limitation of the Operating System.

Unix-like systems may impose limits at the application level (none exist at the input stream level).

Actually, the limitation is not the "console application".

I never claimed (or believed or implied) that the limitation arises in "the console application". That term, as commonly used, refers to an executable which is marked as requiring a console server process to run in tandem with the client process running the said executable.

It is the internal Windows input line buffer and is quite independent of the application that is attached to the "spigot end" of the Windows input queue.

I'm puzzled by what "the internal Windows input line buffer" is supposed to mean. I am quite sure that there is no such thing shared among applications.

I am also sure that the console processes¹ are where the pasting truncation is happening. It is those processes which are called upon to respond to GUI events and, for some sequences of such, collect clipboard text content and feed it into the the standard input stream for the hosted "console application".

It is those "stock" console server processes which are electing to truncate clipboard text as it is fed to their client process. It would be perfectly possible to write a less penurious console host which would feed any amount of text it could grab from the clipboard API to its client "console application". But the stock ones do not. As I said.

I think that when you seek to engage in corrective education, you need to respond to what is actually said rather than a hasty misinterpretation.

1. ^{^} The stock consoles on Windows systems today are running instances of one or two Windows applications, the legacy conhost.exe or the newer OpenConsole.exe .

I am also sure that the console processes1 are where the pasting truncation is happening. It is those processes which are called upon to respond to GUI events and, for some sequences of such, collect clipboard text content and feed it into the the standard input stream for the hosted "console application".

No. The limitation is on anything that reads "line input" from the Windows input queue. You will find the exact same "block" limitation when copying and pasting into, for example, Word, Excel, PowerPoint, Notepad, and on and on. Multiple blocks (lines) can be "pasted" but there is a limitation on the size of each "block".

These are not "console" applications which run under the "Windows input queue" to "normal file stream I/O" adaption layer known colloquially as the "console host", but rather native hooey-gooey applications.

(Edited to save backslashes from death by markup.)

If you run the following¹ from an OS shell: perl -e "print '/', '*'x99999, '/ select \'long line\';';" | clip , you will find that you can then paste a very long "line" into any Windows GUI application that does not itself elect to ignore part of the block. Notepad is one such. Those would include the console host apps if they had been written with fewer stingy assumptions.

These are not "console" applications which run under the "Windows input queue"

I do not know what you are going on about here. The message queues which GUI applications rely upon are per-process. You cannot speak of "the input queue". But that does not matter. Clipboard content never reaches message queues under normal circumstances. (One could make that happen using API calls.) An application which learns of available clipboard content and a user's desire to access it uses API calls to get that content. And as you can see, by running the above code and typing control-V into a notepad text window, no "block" limitation or other hooey is involved. That little query will show up at the end.

1. ^{^} These are a well-known application and a little utility provided by Windows in its .../system32 directory.

Actually, no. Windows only has one input stream line buffer handler. The "application" on the other end of the input stream handler is immaterial.

The "paste line limit" in Windows 10 22H2 is 4096. This is irrespective of the application that is reading the line buffered console input stream.