This is as it should be.
Can you give an example of any other utility or program that continues
reading its input after instructed to exit? I can't find one. The most
obvious case of a program that does this is the
the ["head"][1] utility. It also simply stops reading its input and exits once
it acquires the requested number of lines. Upstream programs that are
concerned about broken pipes will complain. I cannot come up with any
other program that behaves differently. Why should SQLite be any
different?
What if I have a 1MB script in which ".exit" occurs on the 5th line. You
would have SQLite read the entire 1MB just in case the script was piped in?
I don't think so.
The ".exit" command means "stop reading input and exit". You are
asking to redefine ".exit" to mean "read and ignore all subsequent input
and then quit". That is a very different thing, and something I do not
want to support.
If you really need to avoid broken pipe errors, I suggest you write a new
utility program that does that for you. Here is a TCL script called
"shunt.tcl" that transfers content from input to output, but if the output
pipe closes, it continues reading the input to avoid complaints from the
upstream producers:
> ~~~~
while {![eof stdin]} {
if {[catch {puts [gets stdin]; flush stdout}]} {
while {![eof stdin]} {gets stdin}
}
}
~~~~
With this program you could do:
> ~~~~
ftype sqlite3=cmd /c "type %1 | tclsh shunt.tcl | c:\bins\sqlite3.exe -batch %*"
~~~~
The shunt.tcl script will nicely catch and suppress the broken pipe error
for you. That would be the proper solution to this problem.
The sqlite3.exe program is currently working as it ought with respect
to the .exit command and reading standard input.
[1]: https://en.wikipedia.org/wiki/Head_(Unix)