starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Console "Discard Old Duplicates" doesn't apply in Windows Terminal #17941

New Issue
Open
opened 2026-01-31 05:59:11 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 05:59:11 +00:00
Owner
Copy Link

Originally created by @stanio on GitHub (Jul 15, 2022).

Windows Terminal version

1.14.1861.0

Windows build number

10.0.19043.1826

Other Software

No response

Steps to reproduce

  • Open a legacy "Command Prompt" console;

  • From the window menu (top-right icon) select "Defaults";

  • Check "Discard Old Duplicates" in the "Command History" options group, and "OK" to apply;

    console-properties

  • Open a "Command Prompt" in Windows Terminal, and enter commands in succession:

    dir
dir /b
dir
dir /b
dir
dir /b

Expected Behavior

The command buffer should discard previous duplicate entries, as I'm seeing in a legacy "Command Prompt" console – pressing F7 reveals:

legacy-console-buffer

Actual Behavior

The "Command Prompt" in Windows Terminal doesn't appear to honor the "Discard Old Duplicates" setting – pressing F7 reveals:

wterm-console-buffer

This often causes the inconvenience of losing previous command history, after repeating a few of the same commands in succession for some time.

Originally created by @stanio on GitHub (Jul 15, 2022). ### Windows Terminal version 1.14.1861.0 ### Windows build number 10.0.19043.1826 ### Other Software _No response_ ### Steps to reproduce - Open a legacy "Command Prompt" console; - From the window menu (top-right icon) select "Defaults"; - Check "Discard Old Duplicates" in the "Command History" options group, and "OK" to apply; ![console-properties](https://user-images.githubusercontent.com/1247730/179306109-608d22dc-f1f8-45fe-8c94-adc8183ec78b.png) - Open a "Command Prompt" in Windows Terminal, and enter commands in succession: ``` dir dir /b dir dir /b dir dir /b ``` ### Expected Behavior The command buffer should discard previous duplicate entries, as I'm seeing in a legacy "Command Prompt" console – pressing <kbd>F7</kbd> reveals: ![legacy-console-buffer](https://user-images.githubusercontent.com/1247730/179306239-3644108c-0fe8-4246-8fb5-3f3ca17d9861.png) ### Actual Behavior The "Command Prompt" in Windows Terminal doesn't appear to honor the "Discard Old Duplicates" setting – pressing <kbd>F7</kbd> reveals: ![wterm-console-buffer](https://user-images.githubusercontent.com/1247730/179306911-58b46cec-c448-4ddb-9f65-501d45639ceb.png) This often causes the inconvenience of losing previous command history, after repeating a few of the same commands in succession for some time.
claunia commented 2026-01-31 05:59:12 +00:00
Author
Owner
Copy Link

@stanio commented on GitHub (Jul 15, 2022):

FWIW, I'm not sure this is a Windows Terminal issue, as I'm noticing every time I open the (legacy) "Console Windows Properties" I'm seeing the "Discard Old Duplicates" setting unchecked while I'm seeing "HistoryNoDup"=dword:00000001 in the Windows Registry:

windows-registry

I'm observing this UI(?) quirk on at least two Windows 10 machines.

@stanio commented on GitHub (Jul 15, 2022): FWIW, I'm not sure this is a Windows Terminal issue, as I'm noticing every time I open the (legacy) "Console Windows Properties" I'm seeing the "Discard Old Duplicates" setting unchecked while I'm seeing `"HistoryNoDup"=dword:00000001` in the Windows Registry: ![windows-registry](https://user-images.githubusercontent.com/1247730/179308067-53c52a26-dba9-4211-a792-6f2e091d89d7.png) I'm observing this UI(?) quirk on at least two Windows 10 machines.
claunia commented 2026-01-31 05:59:12 +00:00
Author
Owner
Copy Link

@stanio commented on GitHub (Jul 16, 2022):

More details – if I repeat just the same last command, it doesn't get multiplied to the end of the command history:

>dir
>dir /b
>dir
>dir
>dir

F7 (doskey /?):

┌────────────────────────────────────────┐
│0: dir                                  │
│1: dir /b                               │
│2: dir                                  │
│                                        │
│                                        │
│                                        │
│                                        │
│                                        │
│                                        │
│                                        │
└────────────────────────────────────────┘

So it is likely a half-baked port of the original "Discard Old Duplicates" implementation.

My workflow involves repeating 2-3 commands (build, deploy, cls) for some time. After that, I want to quickly select and execute some other command(s) I've executed previously. The current behavior breaks it for me.

@stanio commented on GitHub (Jul 16, 2022): More details – if I repeat just the same last command, it doesn't get multiplied to the end of the command history: ``` >dir >dir /b >dir >dir >dir ``` <kbd>F7</kbd> (`doskey /?`): ``` ┌────────────────────────────────────────┐ │0: dir │ │1: dir /b │ │2: dir │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────┘ ``` So it is likely a half-baked port of the original "Discard Old Duplicates" implementation. My workflow involves repeating 2-3 commands (build, deploy, `cls`) for some time. After that, I want to quickly select and execute some other command(s) I've executed previously. The current behavior breaks it for me.
claunia commented 2026-01-31 05:59:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 19, 2022):

This is probably another face of #2558. When run in ConPTY (read: the terminal), the console just ignores most settings. That might have been a mis-play. We may want to keep around the history settings, but just ignore the "appearance" ones.

Ultimately, this has the same root cause as that issue, so I'm gonna close it as a dupe for bookkeeping purposes. Thanks!

/dup #2558

@zadjii-msft commented on GitHub (Jul 19, 2022): This is probably another face of #2558. When run in ConPTY (read: the terminal), the console just ignores most settings. That might have been a mis-play. We may want to keep around the history settings, but just ignore the "appearance" ones. Ultimately, this has the same root cause as that issue, so I'm gonna close it as a dupe for bookkeeping purposes. Thanks! /dup #2558
claunia commented 2026-01-31 05:59:13 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 19, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jul 19, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 05:59:13 +00:00
Author
Owner
Copy Link

@stanio commented on GitHub (Jul 19, 2022):

Just want to clarify my problem is not that the Windows Terminal doesn't appear to obey the "Discard Old Duplicates" option. It appears to implement some form of it – "discards" just the last command if it matches the previous one. It might be doing it by default, not obeying the original setting (haven't verified explicitly) but this issue is about not matching the original "Discard Old Duplicates" behavior. I suspect even if the setting is read from the Console, the Terminal behavior might still be left broken (at least for me).

@stanio commented on GitHub (Jul 19, 2022): Just want to clarify my problem is not that the Windows Terminal doesn't appear to obey the "Discard Old Duplicates" option. It appears to implement some form of it – "discards" just the last command if it matches the previous one. It might be doing it by default, not obeying the original setting (haven't verified explicitly) but this issue is about not matching the original "Discard Old Duplicates" behavior. I suspect even if the setting is read from the Console, the Terminal behavior might still be left broken (at least for me).
claunia commented 2026-01-31 05:59:13 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 19, 2022):

Yeah, I think this one is worth tracking. Even in its default configuration (read: enabled) it doesn't do what it says on the tin.

@DHowett commented on GitHub (Jul 19, 2022): Yeah, I think this one is worth tracking. Even in its default configuration (read: enabled) it doesn't do what it says on the tin.
claunia commented 2026-01-31 05:59:14 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 20, 2022):

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.

@ghost commented on GitHub (Jul 20, 2022): This issue has been marked as duplicate and has not had any activity for **1 day**. It will be closed for housekeeping purposes.
claunia commented 2026-01-31 05:59:14 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 20, 2022):

Frick, sorry, I didn't fix the tags and the bot went wild.

@DHowett commented on GitHub (Jul 20, 2022): Frick, sorry, I didn't fix the tags and the bot went wild.
claunia commented 2026-01-31 05:59:15 +00:00
Author
Owner
Copy Link

@cniggeler commented on GitHub (Mar 1, 2025):

Hi, it's been a couple years and I'd like to ping the status. I'm using the command prompt profile in Terminal 1.18.10301.0, which doesn't have the checkbox described in this original post, but I continue to see duplicate entries in history. Or are there workarounds? For example,

  • Is there some setting I can add to the settings.json file?
  • Would Set-PSReadLineOption -HistoryNoDuplicates:$True work even though I don't use Powershell and this is the command prompt profile?

Side note: why isn't Set-PSReadLineOption -HistoryNoDuplicates:$True the default behavior? In other words, what advantage is there to having exact duplicates in the history, no matter what type of shell you're running?

Thanks!

@cniggeler commented on GitHub (Mar 1, 2025): Hi, it's been a couple years and I'd like to ping the status. I'm using the command prompt profile in Terminal 1.18.10301.0, which doesn't have the checkbox described in this original post, but I continue to see duplicate entries in <F7> history. Or are there workarounds? For example, - Is there some setting I can add to the settings.json file? - Would Set-PSReadLineOption -HistoryNoDuplicates:$True work even though I don't use Powershell and this is the command prompt profile? Side note: why isn't Set-PSReadLineOption -HistoryNoDuplicates:$True the default behavior? In other words, what advantage is there to having exact duplicates in the history, no matter what type of shell you're running? Thanks!
claunia commented 2026-01-31 05:59:15 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 3, 2025):

Ah, it looks like we didn't link up the pull request and associated issue that caused us to reopen this! When we first fixed it, we just flipped that option on by default for everyone in Terminal. It turned out to not have been the right call. There was a lot of spirited discussion about it.

The console hosting part of the subsystem expressly ignores things set in the registry, in part because by the time the session is established and we know what application we'll be hosting we wouldn't be able to apply application-specific settings from the same registry keys. So, ideally we would allow the host to configure this. Leonard may have more thoughts on why we don't currently or whether that fits in with the plan to move hosting in-process and give it a nice shapely API...

But TL;DR we don't have the infrastructure today to expose that in Terminal's settings and we don't have the confidence to read it from conhost's settings.

Reopened in #18229, related to #18138, discussion in #17797.

Side note ...

Excellent question for the PowerShell or PSReadline folks!

@DHowett commented on GitHub (Mar 3, 2025): Ah, it looks like we didn't link up the pull request and associated issue that caused us to reopen this! When we first fixed it, we just flipped that option on by default for everyone in Terminal. It turned out to not have been the right call. There was a lot of spirited discussion about it. The console hosting part of the subsystem expressly ignores things set in the registry, in part because by the time the session is established and we know what application we'll be hosting we wouldn't be able to apply application-specific settings from the same registry keys. So, _ideally_ we would allow the host to configure this. Leonard may have more thoughts on why we don't currently or whether that fits in with the plan to move hosting in-process and give it a nice shapely API... But TL;DR we don't have the infrastructure today to expose that in _Terminal's_ settings and we don't have the confidence to read it from _conhost's_ settings. Reopened in #18229, related to #18138, discussion in #17797. > Side note ... Excellent question for the PowerShell or PSReadline folks!
claunia commented 2026-01-31 05:59:15 +00:00
Author
Owner
Copy Link

@stanio commented on GitHub (Mar 9, 2025):

A possible workaround I've been using for quite some time now is installing Clink. It has the "discard old duplicates" behavior by default and provides more features one may find useful.

@stanio commented on GitHub (Mar 9, 2025): A possible workaround I've been using for quite some time now is installing [Clink](https://chrisant996.github.io/clink/). It has the "discard old duplicates" behavior by default and provides more features one may find useful.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-CookedRead Help Wanted Issue-Bug Needs-Tag-Fix Priority-2 Product-Conhost
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17941
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?