sqlcl Ctrl+C handler

user11973317

Hello,

there is a difference in handling Ctrl+C keyboard signal between older and new sqlcl versions.

Now pressing Ctrl+C ends sqlcl tool. In earlier versions pressing Ctrl+C  didn't terminate sqlcl tool.

Could you bring the old behaviour back ? I think it was better before, it was consistent with sqlplus in unix / linux Ctrl+C - as it never close the tool, but only breaks the line.

Or maybe there is a way to customise the Ctrl+C handling in sqlcl via some kind of parameter / settitng ?

New versions:

C:\Users\user>sql /nolog

SQLcl: Release 18.4 Production on Wt lut 26 01:21:49 2019

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

01:22:31 @>version

Oracle SQLDeveloper Command-Line (SQLcl) version: 18.4.0.0

01:22:50 @>^C

C:\Users\user>  ---------> CTRL+C ends sqlcl program

Old version:

C:\Users\user>sql /nolog

SQLcl: Release 17.3.0 Production on Wt lut 26 01:23:18 2019

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

01:23:19 @>version

Oracle SQLDeveloper Command-Line (SQLcl) version: 17.3.0.256.1818

01:23:22 @>

01:39:19 @>

<<pressing Ctrl+C here>

01:39:20 @&gt; ---> CTRL+C doesn't end sqlcl program

Piotr

Glen Conway

Yeah, testing on Windows, the change in behavior occurred in release 18.2

User_H3J7U

20.3 problem again.

C:\>sql /nolog

Picked up JAVA_TOOL_OPTIONS: -Dnashorn.args=--no-deprecation-warning

SQLcl: Release 20.3 Production on вт нояб. 24 00:33:55 2020

Copyright (c) 1982, 2020, Oracle. All rights reserved.

SQL> ^C

C:\>

Pressing ctrl-c while running query aborts sql.exe, but sql is still active on the server.

C:\>java -version

Picked up JAVA_TOOL_OPTIONS: -Dnashorn.args=--no-deprecation-warning

java version "11.0.9" 2020-10-20 LTS

Java(TM) SE Runtime Environment 18.9 (build 11.0.9+7-LTS)

Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)

Billy Verreynne

Also an issue with sqlplus as I detailed in https://community.oracle.com/tech/developers/discussion/4174536/oci-behaviour-of-12c-dedicated-server-process-to-a-client-ocibreak-call#latest

No answers as to why this behaviour is now different.