Discard old duplicates needs to be case-sensitive

[cniggeler]

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"!

[zadjii-msft]

Ruh-roh: 6bc2b4a#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

[DHowett]

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,

[cniggeler]

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]

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.

[zadjii-msft]

(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.)

[cniggeler]

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!

[DHowett]

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")?

[cniggeler]

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?