Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

dotnet-suggest: Don't duplicate registration entries, don't return false matches, and be more careful about casing

Aperta
  • Qualcosa non va?
#2,749 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
csharp
Ambito
cli

Direzione di ricerca

Inizia dalla registrazione di dotnet-suggest e da FileSuggestionRegistration.FindRegistration(), in particolare dal percorso di registrazione e dal ciclo di ricerca per prefisso. Verifica il comportamento attuale per le voci duplicate, le corrispondenze iniziali rispetto a quelle finali, i prefissi falsi e la distinzione tra maiuscole e minuscole nelle diverse piattaforme. Il lavoro è completato quando la registrazione evita i duplicati, la ricerca restituisce solo la voce prevista senza proseguire inutilmente e la distinzione tra maiuscole e minuscole segue il comportamento della piattaforma selezionata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

dotnet-suggest is pretty simple in its handling of registrations.

It's just a utf-8 text file with one executable path per line that gets scanned line by line from start to end when searching, returning the last "match" found (which is also just a StartsWith match, and thus can return false positives), and which blindly appends to the file on registration, so long as the provided path exists. It also performs its search explicitly as StringComparison.OrdinalIgnoreCase.

These have a few undesirable consequences:

  1. Entries are duplicated if the same value is given to dotnet-suggest register --command-path <command-path>
  2. The search for a match continues even after a match is found.
  3. False matches can be returned, such as if there is a registration for /path/to/file and /path/to/fileThatIsNotTheOneYouWant, which will return the last of those two entries, even if it is /path/to/fileThatIsNotTheOneYouWant but it was searching for /path/to/file.
  4. The StringComparison.OrdinalIgnoreCase string comparison can result in invalid completions on case-sensitive file systems, which could lead to failure to launch the target to retrieve the completions for it, if the command line text does not match the case of the actual executable but does match the case of the entry in the list. Further, if two files differ in name only by case (which is also legal on Windows, BTW), or if you have a directory structure that looks like the following example, false matches can also occur:
/a/b    <-- This is a file named b in directory /a
/a/B/c  <-- This is a file named c in directory /a/B/

Searching for /a/b will, with the current code, return the second entry as the match, due to both the case-insensitive search and the last-one-wins match strategy.

(1) can be avoided at registration time by just making sure the entry doesn't already exist. It doesn't really matter if the registration operation is made more expensive by doing so, because registration isn't being done frequently, and isn't being done in a context where a brief delay to perform that scan is objectionable.

(2) and (3) can be resolved by returning as soon as a match is found.

It seems to me that it is most important for it to be optimized around the search case, since that is what gets invoked more frequently and in a context wherein the user expects as little delay as possible.

(4) just needs to either have an OSPlatform guard to perform case-sensitive searches on not-windows and case-insensitive searches on Windows, or else simply always perform StringComparison.Ordinal searches on all platforms.[^SensitiveSubject]

There are plenty of other pretty low-complexity ways to make it even smarter than the above simplistic suggestions, such as maintaining the list in sorted order when registering and then performing searches by binary search, and/or by using fixed-width lines to make seeking within the file possible without having to read the whole thing into memory (which would make doing a binary search even more efficient for example). But even just de-duplicating it and returning the first prefix match rather than scanning the entire file and then returning the last prefix match indiscriminately would be improvements over the current implementation, and actually result in fewer lines of code than are currently there, since that temporary string variable named completionTarget in FileSuggestionRegistration.FindRegistration() would go away entirely, along with the extra check for that variable being null that is after the loop.

[^SensitiveSubject]: Windows is case-aware and file naming is case sensitive in Windows, so this would be the most technically correct (the best kind), though of course there is the obvious argument that, since everything else about Windows is case-lenient, enforcing case-sensitivity could be confusing, due to user expectations.

Lingua principale
C#
Stelle
3.7k
Fork
434
Merge medio
4h 46m
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/command-line-api

Tutte le issue di dotnet/command-line-api

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.