Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,749 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
csharp
Lĩnh vực
cli

Hướng nghiên cứu

Bắt đầu với việc đăng ký dotnet-suggest và FileSuggestionRegistration.FindRegistration(), đặc biệt là đường dẫn đăng ký và vòng lặp tìm kiếm theo tiền tố. Xác minh hành vi hiện tại đối với các mục trùng lặp, kết quả khớp đầu tiên so với kết quả khớp cuối cùng, các tiền tố sai và cách phân biệt chữ hoa chữ thường trên các nền tảng. Hoàn tất có nghĩa là việc đăng ký tránh các mục trùng lặp, tìm kiếm chỉ trả về mục dự định mà không tiếp tục không cần thiết, và cách phân biệt chữ hoa chữ thường tuân theo hành vi của nền tảng được chọn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C#
Star
3.7k
Fork
434
Merge trung bình
4 giờ 46 phút
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/command-line-api

Tất cả issue của dotnet/command-line-api

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.