Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can't cycle through command history using the down-arrow #18138

Open
dbc60 opened this issue Nov 2, 2024 · 4 comments · May be fixed by #18229
Open

Can't cycle through command history using the down-arrow #18138

dbc60 opened this issue Nov 2, 2024 · 4 comments · May be fixed by #18229
Assignees
@lhecker
Labels
Area-CookedRead The cmd.exe COOKED_READ handling In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Conhost For issues in the Console codebase
Milestone
Terminal v1.23

Comments

@dbc60
Copy link

dbc60 commented Nov 2, 2024

Windows Terminal version

1.21.2911.0

Windows build number

10.0.22631.4391

Other Software

No response

Steps to reproduce

I used to be able to run

> echo 1
1
> echo 2
2
> echo 3
3

and then press UP ARROW three times to repeat echo 1 and then DOWN ARROW to cycle through echo 2, echo 3, echo 1, etc. Now the first DOWN ARROW does nothing.

I think both Command Prompt and PowerShell had this behavior. I do know I used that pattern of cycling through the history for Command Prompt quite frequently, but now I find that I must press UP ARROW three times each time I want to cycle through the last three commands. It would be nice to have the old behavior back.

I haven't found any documentation or bug reports that addresses this issue. Thanks in advance for your help.

Expected Behavior

After pressing UP ARROW three times and ENTER to execute the third command back in history, I expected pressing DOWN ARROW followed by ENTER to execute each of the past 3 commands in sequence ad infinitum.

Actual Behavior

After pressing UP ARROW three times and ENTER to execute the third command back in history, pressing DOWN ARROW does nothing. No previous command is recalled from history.
@dbc60 dbc60 added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Nov 2, 2024
@lhecker lhecker self-assigned this Nov 4, 2024
@lhecker lhecker added Product-Conhost For issues in the Console codebase Priority-3 A description (P3) Area-CookedRead The cmd.exe COOKED_READ handling and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Nov 4, 2024
@lhecker lhecker added this to the Terminal v1.23 milestone Nov 4, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Nov 4, 2024
@github-project-automation github-project-automation bot moved this to To Cherry Pick in 1.22 Servicing Pipeline Nov 4, 2024
@github-project-automation github-project-automation bot moved this to To Cherry Pick in 1.21 Servicing Pipeline Nov 4, 2024
@lhecker lhecker moved this from To Cherry Pick to To Consider in 1.22 Servicing Pipeline Nov 4, 2024
@lhecker lhecker moved this from To Cherry Pick to To Consider in 1.21 Servicing Pipeline Nov 4, 2024
@lhecker lhecker removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 4, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Nov 4, 2024
@ikkierie
Copy link

ikkierie commented Nov 5, 2024

As a temporary measure, downgrading to release v1.21.2361.0 or lower rolls back this change.

@dbc60
Copy link
Author

dbc60 commented Nov 5, 2024 •
edited
Loading

Thank you. I rolled back to v1.21.2361.0 (which works well enough and resolves this issue for the time being) and look forward to the release of v1.23.

@lhecker
Copy link
Member

lhecker commented Nov 21, 2024 •
edited
Loading

Apparently that's how cmd has always worked if "Discard old duplicates" is enabled, huh. I wonder if I should double-down by changing the "Discard old duplicates" behavior and add the "circling" that you describe, or if I should revert enabling it by default under Windows Terminal.

@ikkierie
Copy link

i think a problem here is that the "replay" behaviour working consistently is dependent on not deleting old duplicate commands, since if you delete an old duplicate, you change the command sequence

i.e. with dedup

cls
echo 1
echo 2
echo 3
...
echo 2

means that "replaying" from cls onwards would then run

cls
echo 1
echo 3

i think that, if there can't be configuration on the user end, not having dedup is the better option since the only downside (afaik) is that it's inefficient usage of the history buffer (and to my knowledge that shoudn't be an issue if the history buffer is set to any reasonable size)

@lhecker lhecker linked a pull request Nov 21, 2024 that will close this issue
Open
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label Nov 21, 2024
@lhecker lhecker mentioned this issue Nov 21, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lhecker lhecker

Labels
Area-CookedRead The cmd.exe COOKED_READ handling In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Conhost For issues in the Console codebase
Projects
1.21 Servicing Pipeline
Status: To Consider
1.22 Servicing Pipeline
Status: To Consider
Milestone
Terminal v1.23
Development

Successfully merging a pull request may close this issue.

Revert "Dedup command history by default (#17852)" microsoft/terminal
3 participants
@lhecker @dbc60 @ikkierie