What is going on with the command history scroll back?! #18743
-
|
I use a cmd.exe shell in windows terminal. Up until 5 months ago the command history behaviour was the same as cmd.exe, ie if you use the up arrow to scroll up to a previous command, run it, it does the weird thing where it preserves your "cursor" into the history such that you then have to press down arrow to the command before last. This is in contrast to the bash shell behaviour where after every run command you are at the bottom of the history, so down arrow does nothing. It's a weird behaviour but I was used to it. 5 months ago, I think after a windows update, this suddenly changed so it now had the bash behaviour. Annoying that it randomly happened without my input, but I actually prefer that behaviour so fine. Over the last few days I've had windows terminal crash 3 times, and on the 3rd restart the scroll back behaviour has now reverted to the cmd.exe one. How can I get it back to the bash style? It also seems the F7 history overlay is now broken. It works fine in cmd.exe, but through windows terminal it doesn't. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
|
The changes to the history order came about when trying to avoid duplicate entries in the history (issue #17797). But this broke the workflow for people that relied on using the history to repeat a sequence of commands (issue #18138), so that change was reverted. The original issue has been reopened to track the problem. See also issue #13515.
This was an intentional change in the design - it was discussed in the 1.22 release blog post. It was necessary to get the history working with the new conpty "passthrough" implementation, which requires that menu to be implemented with pure VT sequences, and most terminals don't support the functionality needed to implement overlay windows with VT. That said, it's possible we may one day be able to get the old UI back on terminals that do have the required functionality. |
Beta Was this translation helpful? Give feedback.
-
But that's exactly what the preview releases are for! New features are previewed so users can provide feedback on what works and what doesn't. Sometimes things get reverted. And I don't think the implications of the change were obvious at the time. It wasn't so much a decision to use "bash style history" vs "cmd style history". That was just a side effect of removing duplicate entries from the history. There is actually an option for this in the old conhost terminal, but that kind of option is not as easy to implement in Windows Terminal because it isn't tightly coupled to the shell in the way that conhost is. This is discussed in #13515. |
Beta Was this translation helpful? Give feedback.
-
|
I am not using the preview? I don't use it exactly to avoid having my time wasted with annoying issues like this... |
Beta Was this translation helpful? Give feedback.
-
|
OK, sorry, I didn't think the original change had made it into the main build, but it looks like it was backported in one of the servicing releases. |
Beta Was this translation helpful? Give feedback.
-
|
@charlesataylor I fear I should personally apologize. James is correct, and I'll provide a little bit of additional detail. The "discard old duplicates" feature is disabled by default on the vintage Windows Console Host, and when we launched Terminal we left it disabled by default but neglected to offer a configuration option for it. As you've rightly pointed out, considering the history of conhost and the advent of Terminal in 2019 it remained that way for a collective three decades. In September 2024, to respond to some user reports that it didn't behave the way users expected in that decade, we changed the default (#17852) for Terminal users. That new behavior shipped shortly thereafter--on 27th September--in Terminal 1.21.2701.0. Users who had been accustomed to the way it had worked for the preceding few decades showed up to let us know that we had erred, so we reverted the behavior to the standing default on 20th November 2024 (in #18299). That change did not make it to the 1.21 (then "stable") release train, but did make it into the 1.22 (then "preview") one. I am not sure why; it was marked "Consider" instead of "Do." As a result, it was only released to the stable channel users who had experienced the newly broken behavior on 5th February 2025 with the release of Terminal 1.22.10352.0. It's been working its way through our various release "gates" since then, so five months sounds about right. As the maintainer and the person with whom all bucks stop on this project: I apologize that I have wasted your time and taken away five or so months of new muscle memory. I'd encourage you to track issue #17797 so you can learn when we've released a more satisfactory update. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for that @DHowett |
Beta Was this translation helpful? Give feedback.
The changes to the history order came about when trying to avoid duplicate entries in the history (issue #17797). But this broke the workflow for people that relied on using the history to repeat a sequence of commands (issue #18138), so that change was reverted. The original issue has been reopened to track the problem. See also issue #13515.
This was an intentional change in the design - it was discussed in the 1.22 release blog post. It was necessary to get the history working with the new conpty "passthrough" implementation, which requires that menu to be implemented with pure VT sequences, and most terminals don't support the func…