(Edited to describe a change under consideration which addresses this behavior.) The CLI's line collection process applies just a few rules, which can be summarized as: 1. If the line begins with '.' and is the first since the last SQL or meta-command was processed, then it is a single-line meta-command and processed as such. 2. If the line ends with ';' followed by nothing but whitespace<sup>a</sup> and is not within an SQL construct within which that character is considered part of the construct rather than a statement terminator, then the line together with its predecessors (that were not meta-commands) is submitted for SQL execution. (prepare, step with output, finalize) In your example, the "--" which begins the line, per all SQL standards, makes that and the remainder of the line, whatever it may be, a comment. It would have to be a special cased handler that would treat ';' as a SQL terminator only if it appears at the end and outside of all lexically delimited constructs<sup>b</sup> **except** end-of-line comments. I do not see how the present behavior is weird. Should an end-of-line semicolon within a block comment also terminate the SQL to avoid this weirdness? (Added via edit:)<br> This additional summarized rule would cure your script problem and should be harmless in all circumstances I am imagining: \3. As non-meta-command lines are accumulated, at any time that they constitute a complete SQL construct which is nothing but whitespace<sup>a</sup> the accumulation is discarded, the primary prompt is issued (if in interactive mode), and line processing reverts to the state where either meta-commands or SQL (finally ending with ';') are accepted. Comments on any difficulties arising from this approach are more than welcome. ---- a. In this context, "whitespace" includes the usual not-dark characters and SQL comments. b. The "lexically delimited constructs" are quoted strings and identifiers, and end-of-line or block comments.