> This is a bit odd: ... Here is a screen-scrape, just now taken:<code> larry@Bit-Booger:~/SQLiteDev/LibTrunk$ ./sqlite3 SQLite version 3.37.0 2021-10-01 22:48:52 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite\> .import -csv "|iconv -f L1 \< pets.csv | grep '^M' | cat -" incoming sqlite\> .header on sqlite\> select * from incoming; Moses|dog|12 Meowser|cat|17 sqlite\> </code> I adjusted your inconv from encoding to reflect ones listed via -l, and replaced your "tail -r" with something that does not break the pipe (as happens with Ubuntu 20.04's tail which knows not the -r option.) However, using an equivalent to your posted .import pipe extravaganza, I get:<code> sqlite\> .import -csv "|iconv -f l1 \< pets.csv | grep '^\\"20' | tail -r" incoming tail: invalid option -- 'r' Try 'tail --help' for more information. \<pipe\>: empty file sqlite\> select * from sqlite_schema; ...\> ; ...\> </code> This appears to replicate your problem. There is a simple, near-term solution: Do not subject the CLI's piped-input-accepting commands to broken pipes. Meanwhile, I will investigate why such expectable input produces this strange result. (A 2nd work-around appended via edit:) It seems that output reaching a shared stderr stream may be involved in this problem:<code> sqlite\> .import "|cat /dev/null" junk \<pipe\>: empty file sqlite\> select * from sqlite_schema; sqlite\> .import -csv "|iconv -f L1 \< pets.csv | grep '^M' | tail -r 2\>/dev/null" incoming \<pipe\>: empty file sqlite\> </code> Note that an empty input pipe, by itself, does not trigger the misbehavior. It can be avoided by merely diverting the pipe-breaker's moaning away from the same stderr stream the CLI is using. So that would be another short-term work-around. sqlite>