[SERVER-4460] Improve ctrl-C handling in the shell Created: 08/Dec/11  Updated: 06/Dec/22  Resolved: 19/Nov/21

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Tad Marshall Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Won't Fix Votes: 14
Labels: move-stm, platforms-re-triaged, polish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-7616 Assertion error in mongo shell Closed
is related to SERVER-2986 Mongo CLI responds poorly to the use ... Closed
is related to SERVER-32777 CTRL-C in shell during op should not ... Closed
Assigned Teams:
Server Tooling & Methods
Participants:

 Description   

In the current code, hitting ctrl-C in the shell behaves differently on Windows than on Linux, and in neither does it cleanly exit multi-line mode the way it did in Linux version 1.8.

1) Capture ctrl-C at the "read from keyboard" step in Windows like we do in Linux and respond the same way in both;
2) Cleanly exit multi-line mode in both Linux and Windows the way we did in 1.8;
3) Decide whether ctrl-C should ever exit the shell (it does now) or if it should just cancel the current input line (if executed at an active prompt);
4) Decide what it should do if the shell is waiting for a response from the server.



 Comments   
Comment by Kelsey Schubert [ 05/Apr/21 ]

Hi tukusejssirs@protonmail.com,

For an improved UX, please check out our new shell, which is currently in beta. I've started using this new shell and appreciate the improvements we've made (pressing Ctrl+C once does not exit) and hope that you do too!

Best,
Kelsey

Comment by Tukusej’s Sirs [ 30/Mar/21 ]

I hope this issue is fixed soon. I am a MongoDB newbie and a long-time Linux user. I hate that every time I press Ctrl+C, it quits Mongo Shell. It makes me nervous and makes me try MongoDB no more.

From UX point of view, this issue should be classified as severe UX bug. You should at least make it configurable.

Comment by Glenn Maynard [ 26/Mar/12 ]

^C should start a new prompt, but it should never quit the shell; see GDB and Postgresql, for example. You should be able to press ^C to cancel input or a running operation, without worrying that you might accidentally terminate the shell.

Comment by auto [ 08/Dec/11 ]

Author:

{u'login': u'', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}

Message: SERVER-4458, SERVER-4460 Improve ctrl-C handling in the shell

Repair the incorrect edit I made in "code cleanup" by moving the space
out from between the quotes in 'if ( code.find( "\n\n\n" ) != string::npos )'
Turn off ctrl-C handling by the Console in Windows so we get the ctrl-C
and can decide what to do with it. Handle it the same way in Linux and
Windows. Set the 'gotInterrupted' flag on a ctrl-C so the multi-line
code can exit cleanly on a ctrl-C. This doesn't resolve SERVER-4460
because it doesn't answer the questions about whether to exit the shell
on a ctrl-C nor about what to do if a server command is running.
Branch: master
https://github.com/mongodb/mongo/commit/e5bd79b33f310f4ec2f35a71efd715ef92b9680c

Comment by auto [ 08/Dec/11 ]

Author:

{u'login': u'', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}

Message: SERVER-4458, SERVER-4460 Improve ctrl-C handling in the shell

Repair the incorrect edit I made in "code cleanup" by moving the space
out from between the quotes in 'if ( code.find( "\n\n\n" ) != string::npos )'
Turn off ctrl-C handling by the Console in Windows so we get the ctrl-C
and can decide what to do with it. Handle it the same way in Linux and
Windows. Set the 'gotInterrupted' flag on a ctrl-C so the multi-line
code can exit cleanly on a ctrl-C. This doesn't resolve SERVER-4460
because it doesn't answer the questions about whether to exit the shell
on a ctrl-C nor about what to do if a server command is running.
Branch: master
https://github.com/mongodb/mongo/commit/e5bd79b33f310f4ec2f35a71efd715ef92b9680c

Generated at Thu Feb 08 03:06:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.