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

Discard old duplicates needs to be case-sensitive #5869

New Issue
Closed
opened 2026-01-31 00:23:52 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 00:23:52 +00:00
Owner
Copy Link

Originally created by @cniggeler on GitHub (Jan 12, 2020).

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):
Microsoft Windows [Version 10.0.18362.535]

Any other software? No, none required

Steps to reproduce

Command Prompt Properties - check "Discard Old Duplicates" in history section
Enable the Experimental Console (UNcheck "Use Legacy Console..."

Expected behavior

Run the two commands,
foo /v
foo /V

Then use up-arrow to view the history. You should see BOTH in the history. This is the case for the classic console.

Actual behavior

In the experimental console, only the FIRST instance (foo /v) is preserved. That is, the new console acting case-insensitive, but 'V' and 'v' can have significance to "foo"!

Originally created by @cniggeler on GitHub (Jan 12, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> ```none Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] Windows Terminal version (if applicable): Microsoft Windows [Version 10.0.18362.535] Any other software? No, none required ``` # Steps to reproduce Command Prompt Properties - check "Discard Old Duplicates" in history section Enable the Experimental Console (UNcheck "Use Legacy Console..." # Expected behavior <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> Run the two commands, foo /v foo /V Then use up-arrow to view the history. You should see BOTH in the history. This is the case for the classic console. # Actual behavior <!-- What's actually happening? --> In the experimental console, only the FIRST instance (foo /v) is preserved. That is, the new console acting case-insensitive, but 'V' and 'v' can have significance to "foo"!
claunia commented 2026-01-31 00:23:53 +00:00
Author
Owner
Copy Link

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

Ruh-roh: 6bc2b4af09 (commitcomment-79599160)

Somebody has reported that this changed how F8 expansion works . . . and now I'm wondering if we should have done this to begin with. Or, perhaps, should deduplication and expansion be split apart?

FWIW: The legacy console treats F8 as being case sensitive.

That person was in MSFT:40506961. Tagging for more discussion

@zadjii-msft commented on GitHub (Jul 28, 2022): Ruh-roh: https://github.com/microsoft/terminal/commit/6bc2b4af09cf3032e2fccd405302ffac70fd348c#commitcomment-79599160 > Somebody has reported that this changed how F8 expansion works . . . and now I'm wondering if we should have done this to begin with. Or, perhaps, should deduplication and expansion be split apart? > > FWIW: The legacy console treats F8 as being case _sensitive_. That person was in MSFT:40506961. Tagging for more discussion
claunia commented 2026-01-31 00:23:54 +00:00
Author
Owner
Copy Link

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

Notes from the reporter:

Windows in general is not case sensitive. For example, try to make a file named FOO.txt and one named foo.txt (doesn’t work). Then, use ‘del’ to remove FoO.TxT (works). The documentation for WSL also notes the case-insensitivity of the Windows filesystem.

I know that’s not conhost, but it still feels weird to match on sensitivity when many operations on the command line aren’t case sensitive. Anyway, just my $0.02.

Thanks,

@DHowett commented on GitHub (Jul 28, 2022): Notes from the reporter: > Windows in general is not case sensitive. For example, try to make a file named FOO.txt and one named foo.txt (doesn’t work). Then, use ‘del’ to remove FoO.TxT (works). The documentation for WSL also notes the case-insensitivity of the Windows filesystem. > > I know that’s not conhost, but it still feels weird to match on sensitivity when many operations on the command line aren’t case sensitive. Anyway, just my $0.02. > > Thanks,
claunia commented 2026-01-31 00:23:54 +00:00
Author
Owner
Copy Link

@cniggeler commented on GitHub (Jul 29, 2022):

A couple points to @DHowett comment:

  1. Filesystem is not the same as command line.
  2. You can make the filesystem case-sensitive a la fsutil file setCaseSensitiveInfo
  3. Just because you don't run commands that use case sensitivity, maybe other people do?
c:> cl /v
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '/v'
cl : Command line error D8003 : missing source filename

c:> cl /V
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line error D8004 : '/V' requires an argument
@cniggeler commented on GitHub (Jul 29, 2022): A couple points to @DHowett comment: 1. Filesystem is not the same as command line. 2. You _can_ make the filesystem case-sensitive a la `fsutil file setCaseSensitiveInfo` 3. Just because _you_ don't run commands that use case sensitivity, maybe other people do? ``` c:> cl /v Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line warning D9002 : ignoring unknown option '/v' cl : Command line error D8003 : missing source filename c:> cl /V Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line error D8004 : '/V' requires an argument ```
claunia commented 2026-01-31 00:23:54 +00:00
Author
Owner
Copy Link

@cniggeler commented on GitHub (Jul 29, 2022):

In reply to @zadjii-msft -

Why "ruh-roh"? I know what it means :-) but when I look at the related commitment link, there's not an issue there, at least not that pops up to me.

It seems to me that deduplication and F8-expansion are intertwined for this issue. If deduplicate buffers only upper-case commands, then lower- or mixed-cased commands simply do not exist to F8-expand, right? That is indeed the original behavior of the new terminal as opposed to the console and why I opened this case.

@cniggeler commented on GitHub (Jul 29, 2022): In reply to @zadjii-msft - Why "ruh-roh"? I know what it means :-) but when I look at the related commitment link, there's not an issue there, at least not that pops up to me. It seems to me that deduplication and F8-expansion are intertwined for this issue. If deduplicate buffers only upper-case commands, then lower- or mixed-cased commands simply do not exist to F8-expand, right? That is indeed the original behavior of the new terminal as opposed to the console and why I opened this case.
claunia commented 2026-01-31 00:23:54 +00:00
Author
Owner
Copy Link

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

(FWIW, I put the comments here because this thread had the original context. It's easier to re-open an issue for the sake of work tracking than it is to revert a PR, and reopen the original one. That's at least my thought. )

This is more of a we need to talk about this more. I think we initially instant-approved for the backlog because tHaTs hOw tHe lEgAcY CoNsOlE WoRkEd, but I don't think we ever took pause to ideate on "how should this work". Conhostv2 (and by extension, Terminal) gave us the opportunity to improve bits of the console experience. We should actually consider the ideal behavior here, rather than just the legacy behavior for legacy's sake. (That doesn't mean the legacy behavior isn't what we'll settle on, we just need to have more discussion and come to a definitive agreement here.)

@zadjii-msft commented on GitHub (Jul 29, 2022): (FWIW, I put the comments here because this thread had the original context. It's easier to re-open an issue for the sake of work tracking than it is to revert a PR, and reopen the original one. That's at least my thought. ) This is more of a _we need to talk about this more_. I think we initially instant-approved for the backlog because tHaTs hOw tHe lEgAcY CoNsOlE WoRkEd, but I don't think we ever took pause to ideate on "how _should_ this work". Conhostv2 (and by extension, Terminal) gave us the opportunity to improve bits of the console experience. We should actually consider the ideal behavior here, rather than just the legacy behavior for legacy's sake. (That doesn't mean the legacy behavior _isn't_ what we'll settle on, we just need to have more discussion and come to a definitive agreement here.)
claunia commented 2026-01-31 00:23:55 +00:00
Author
Owner
Copy Link

@cniggeler commented on GitHub (Jul 29, 2022):

I'm all for no-kneejerk reactions, but c'mon, there's such a thing as a smell test. Unless you want Terminal to regress to CP/M, I humbly suggest there's no discussion to be had on this topic!

  • There are NO modern command shells that are not case sensitive.
  • MANY command line applications can have case-sensitive operands. I provided an example of Microsoft's own cl compiler above; gcc is the same.
  • Win10+ CAN have case-sensitive filenames.

So, let's discuss: what could possibly be a "con" to having a case-sensitive history buffer? There's not even a size issue because keeping case-sensitive versions of commands is confined to the user's proscribed history limit!

@cniggeler commented on GitHub (Jul 29, 2022): I'm all for no-kneejerk reactions, but c'mon, there's such a thing as a smell test. Unless you want Terminal to regress to CP/M, I humbly suggest there's no discussion to be had on this topic! - There are NO modern command shells that are not case sensitive. - MANY command line applications can have case-sensitive operands. I provided an example of Microsoft's own cl compiler above; gcc is the same. - Win10+ CAN have case-sensitive filenames. So, let's discuss: what could possibly be a "con" to having a case-sensitive history buffer? There's not even a size issue because keeping case-sensitive versions of commands is confined to the user's proscribed history limit!
claunia commented 2026-01-31 00:23:55 +00:00
Author
Owner
Copy Link

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

Just to be clear: nobody is advocating for reverting this fix and making the history buffer case insensitive.

Somebody reported that F8 history search and expansion became case sensitive, and we traced it back to this fix.

I think there is a fighting chance that history deduplication truly should be case sensitive, and that history search based on a prefix (which on Windows is very unlikely to be case sensitive for the amount of a command you'd likely type before searching, as executables on the PATH are not typically in case sensitive directories) should be case insensitive.

That is what there is to discuss. Do we believe that ease of use ("user can search a case-sensitive history with a case-insensitive needle") can be achieved with a rigorous data model ("history is always case-sensitive")?

@DHowett commented on GitHub (Jul 29, 2022): Just to be clear: nobody is advocating for reverting this fix and making the history buffer case insensitive. Somebody reported that <kbd>F8</kbd> history search and expansion became case sensitive, and we traced it back to this fix. I think there is a fighting chance that history deduplication truly should be case sensitive, and that history search based on a prefix (which on Windows is very unlikely to be case sensitive for the amount of a command you'd likely type before searching, as executables on the `PATH` are not typically in case sensitive directories) should be case **insensitive**. _That_ is what there is to discuss. Do we believe that ease of use ("user can search a case-sensitive history with a case-insensitive needle") can be achieved with a rigorous data model ("history is always case-sensitive")?
claunia commented 2026-01-31 00:23:55 +00:00
Author
Owner
Copy Link

@cniggeler commented on GitHub (Jul 29, 2022):

Appreciate your thoughts and clarification. If I understand correctly, you are now talking solely about the history search being case-insensitive? That is a fine-grained discussion indeed! I don't have an objection, as long as all prior unique commands (case preserved) are presented to me.

I fished around for a counter-example: assume case sensitivity turned on for the filesystem. With PATHEXT and/or file associations, I can enter any old filename, like myfile.docx, at the prompt, and have Word open that file. So if I typed my<F8> and got MySpreadSheet.xlsx as a match, would I be chuffed or huffed? If I took the time to reset the filesystem, answer would be huffed. For 95% of the Windows population, probably OK?

@cniggeler commented on GitHub (Jul 29, 2022): Appreciate your thoughts and clarification. If I understand correctly, you are now talking solely about the history search being case-insensitive? That is a fine-grained discussion indeed! I don't have an objection, as long as _all_ prior unique commands (case preserved) are presented to me. I fished around for a counter-example: assume case sensitivity turned on for the filesystem. With PATHEXT and/or file associations, I can enter any old filename, like myfile.docx, at the prompt, and have Word open that file. So if I typed my&lt;F8&gt; and got MySpreadSheet.xlsx as a match, would I be chuffed or huffed? If I took the time to reset the filesystem, answer would be huffed. For 95% of the Windows population, probably OK?
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 Area-Server Issue-Bug Priority-2 Product-Conhost Resolution-Fix-Committed zInbox-Bug
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#5869
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?