[SERVER-4010] The Windows version of the shell loses scrollback on ctrl-L Created: 04/Oct/11 Updated: 24/Mar/20 Resolved: 24/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 2.0.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Tad Marshall | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | platforms-re-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows |
||
| Participants: |
| Description |
|
In the bash shell and in non-Windows versions of the Mongo shell, you can press ctrl-L at any time to get a clean screen with your current line displayed at the top of the screen. This may add some blank lines to your scrollback buffer (the stuff you can see by moving the window's scrollbar) but it never loses data. In the Windows version of the Mongo shell, ctrl-L overwrites display memory with spaces and will destroy not only the scrollback of the Mongo session but any data that had been stored in scrollback memory before you started the Mongo shell. This is kind of rude and makes ctrl-L a lot less useful in Windows. The Windows version of Mongo shell should emulate bash and not destroy scrollback memory. |
| Comments |
| Comment by Ratika Gandhi [ 24/Mar/20 ] |
|
This is not a priority. |
| Comment by Tad Marshall [ 06/Oct/11 ] |
|
This is mostly fixed in pull request https://github.com/mongodb/mongo/pull/96 but that fix shows some bugs in some cases. This fix does the right thing when there is no scrollback memory (window size == buffer size) (which happens to match the old code's behavior) and it works when the screen buffer is at least twice as large as the window size (which is the default). It fails if the user has set up a testing situation such as my (testing) 70 line buffer with a 50 line window. In this case, the code can leave leftover lines displayed below the redisplayed prompt and user input. Not a showstopper, but ugly. In the normal case, when it works, it does a better job than the non-Windows versions because it can simply move the window's view of the screen buffer, showing a clean screen while losing no scrollback memory other than what had to be lost to show the clean screen. The ESC [ 2 J escape sequence that non-Windows versions have to use deletes data, because it has no choice. |