> 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.