When pasting queries separated by a semicolon with a new line, they are passed as a single query

[vvysotskyi]

For the case when several queries are pasted to the SqlLine, they are passed as a single query:
For example, copy all the next queries:

show databases;
show databases;

and paste them to the SqlLine. It passes all the queries as the single one.
The previous version was submitting the first query, returned its result, and then submitted one by one other queries.

[snuyanzin]

Strange...
Tried to reproduce: it works ok on Windows
while on Linux the behavior is like you described

[vvysotskyi]

@snuyanzin thanks for looking into this issue.

Is it possible that different behavior for Windows is caused by the difference in line ending symbols for Windows and Linux?

[snuyanzin]

Not sure about line endings... at least not at sqlline level (may be somewhere at jline).
Anyway there are several more related cases e.g. when commands are not one-liners (at least one of them) e.g.

  !set csvdelimiter '
  1'
select 1;

these lines are going to be handled as one-line on Windows as well while at 1.5.0 it fails as below

I think it could make sense to have here the similar approach as at #233 where the line is constructed by appending lines from file until the result passes SqlParser.parse or eof. In case the result line passes SqlParser.parse then execute it and start to build the next line while not eof.
Here the difference (and it is not implemented) is that if the resulting line does not pass SqlParser.parse and end of input is reached then this line should be placed with the next prompt (it is allowed by jline api).

The trace from 1.5.0 for the example above

sqlline>   !set csvdelimiter '
java.lang.IllegalArgumentException: A quote should be closed for <'>
        at sqlline.SqlLine.dequote(SqlLine.java:1190)
        at sqlline.SqlLine.split(SqlLine.java:1274)
        at sqlline.SqlLine.split(SqlLine.java:1019)
        at sqlline.SqlLine.split(SqlLine.java:1006)
        at sqlline.SqlLine.split(SqlLine.java:1358)
        at sqlline.Commands.set(Commands.java:526)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.base/java.lang.reflect.Method.invoke(Unknown Source)
        at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
        at sqlline.SqlLine.dispatch(SqlLine.java:643)
        at sqlline.SqlLine.begin(SqlLine.java:510)
        at sqlline.SqlLine.start(SqlLine.java:233)
        at sqlline.SqlLine.main(SqlLine.java:175)
sqlline>   1'
. . . .> select 1;

[Atri0]

Also, there is a case when two SQL queries are submitted in a single line divided by semicolon, like "select * from sys.version; select * from sys.version; "
Actual result: Passed as single query
Expected result: Passed as two queries

[julianhyde]

It might be difficult to split lines on semicolons. It requires knowledge of the underlying DB's scheme for comments, quoting string literals, quoting identifiers. Or maybe we have those already, @snuyanzin?

[snuyanzin]

I guess that before upgrade to jline3 such simple queries

"select * from sys.version; select * from sys.version; "

were processed as 2 queries because sqlline just parsed till the first semicolon (a bit tricky queries failed e.g. mentioned at #129).

We have knowledge about comments, quoting string literals, quoting identifiers at least from Dialect functionality.
Theoretically it is possible to support cases mentioned in the ticket however need to dive deeper into Jline3's parser to research how to tell it that there are several several queries in a command but not one

[snuyanzin]

I was able to find solution and submitted a PR.
Also included tests there.
By the way @vvysotskyi , @Atri0 could you please check your cases if they also work or not?

[vvysotskyi]

@snuyanzin, thanks for the fix, I have checked and with your fix, both cases provided by me and @Atri0 work correctly.

[julianhyde]

Fixed in b8ace84, PR #297. Thanks @snuyanzin!