SQLite Forum

Strange parsing problem in the shell
> 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;

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

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

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.