SQLite Forum

Strange CLI .exit issue
Login
> The problem I reported is both accurate and real. The setup using FTYPE is also 100% correct as is. It expands to a new CMD running the command:<code>
type sample.sql | c:\bins\sqlite3 --batch
</code>

I can see, from running a cmd.exe session (which I take to be your "administrator console"), that it runs ftype commands differently from most others, in that it **does not** expand %-preceded words. That's not surprising because cmd.exe is chock-full of quirky exceptions like that. I suppose I should have known, and so I will cop to an error on my absence of quoting comment. I do not accept that that comment was rude, however.

I also accept Keith's corrective point and explanation that argument expansion by the Windows GUI shell is done in a certain way, different from cmd.exe's interpretation of the same argument expressions. I will cop to the additional error of supposing that those expansions occur the same way. However, I do not accept that my erroneous statement of supposed expansion was rude.

> ... it appears to have solved the problem ... it ... consume all chars until end-of-file upon .exit command.

> I did not ask for an opinion on the correctness of my setup, only of the 'fix'.

I stand by my conclusion that there is nothing to fix. The broken pipe message is not something to be avoided by changing potential consumers to read everything in the stream. The message normally indicates either that there has been a mismatch between what a stream producer produces and what a stream consumer expects, or that the consumer terminated prematurely without consuming what was expected to be consumed. The detection of a "broken pipe" and what to say about it are the responsibility of the invoking shell that setup the "pipe" connections. It would be overly presumptuous, IMO, for a consumer to preclude such reports by consuming all input regardless of its content. While some users may dislike seeing broken pipe reports, others value them as indicators that something unexpected is happening.

In this case, the SQLite shell consumes its standard input up to and including the .quit or .exit meta-command and its terminating newline. It should do no more and no less for valid input. It would be a disfavor to those who (arrange to) pipe input into the SQLite shell to deprive them of the useful diagnostic that there is extra garbage in the pipeline. To those who disagree, I would ask what should be the result of doing this on a *Nix system:<code>
   cat myValidSQLiteShellInput /dev/zero | sqlite3 -batch
</code>?