Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Don't complete duplicate command names#21113

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

MartinGC94
Copy link
Contributor

@MartinGC94MartinGC94 commentedJan 20, 2024•
edited
Loading

PR Summary

Update the duplicate command name check to also take the module name into account when deciding whether or not to add a command with the module name as a prefix.
Before:

TabExpansion2 Find-Module | select -ExpandProperty CompletionMatchesCompletionText            ListItemText ResultType ToolTip--------------            ------------ ---------- -------Find-Module               Find-Module     Command …PowerShellGet\Find-Module Find-Module     Command …PowerShellGet\Find-Module Find-Module     Command …

After:

TabExpansion2 Find-Module | select -ExpandProperty CompletionMatchesCompletionText ListItemText ResultType ToolTip-------------- ------------ ---------- -------Find-Module    Find-Module     Command …

PR Context

Fixes#6765
Get-Command -All returns duplicate commands if multiple versions of the same module exist, or if 2 different modules include the same command name so the tab completion needs to handle this scenario.

PR Checklist

blaisemGH reacted with thumbs up emoji
@pull-request-quantifier-deprecatedPull Request Quantifier (deprecated)

This PR has71 quantified lines of changes. In general, a change size of upto200 lines is ideal for the best PR experience!

Quantification details

Label      : SmallSize       : +54 -17Percentile : 28.4%Total files changed: 2Change summary by file extension:.cs : +28 -17.ps1 : +26 -0

Change counts above are quantified counts, based on thePullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using thecontext generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out theExcluded section from yourprquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in yourprquantifier.yaml context profile.
    • Only use the labels that matter to you,see context specification to customize yourprquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added:+1 -0
  • One line was deleted:+0 -1
  • One line was modified:+1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.

Was this comment helpful?👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@MartinGC94

This comment was marked as outdated.

@microsoft-github-policy-servicemicrosoft-github-policy-servicebot added Review - NeededThe PR is being reviewed labelsJan 28, 2024
@pull-request-quantifier-deprecatedPull Request Quantifier (deprecated)

This PR has73 quantified lines of changes. In general, a change size of upto200 lines is ideal for the best PR experience!

Quantification details

Label      : SmallSize       : +56 -17Percentile : 29.2%Total files changed: 2Change summary by file extension:.cs : +29 -17.ps1 : +27 -0

Change counts above are quantified counts, based on thePullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using thecontext generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out theExcluded section from yourprquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in yourprquantifier.yaml context profile.
    • Only use the labels that matter to you,see context specification to customize yourprquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added:+1 -0
  • One line was deleted:+0 -1
  • One line was modified:+1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.

Was this comment helpful?👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.


results.Add(GetCommandNameCompletionResult(completionName, commandList[0], addAmpersandIfNecessary, quote));
_ = modulesWithCommand.Add(commandInfo.ModuleName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

What ifcommandInfo.ModuleName is null or empty? Are we supposed to add to the set in that case?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The Getter for ModuleName never returns null, it will be an empty string if there's no module. An empty string is fine because it's just a count of the places where the command can be found and if that's 2 or more it should be handled.

Comment on lines 349 to 350
if ((commandInfo.CommandType != CommandTypes.Alias && commandInfo.CommandMetadata.CommandType is not null)
|| (commandInfo.CommandType == CommandTypes.Alias && commandInfo.Definition is not null))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can you please explain this check a little bit? I'm not sure if I understand what it's checking.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It's checking whether or not the source module of the command has been imported. I remember having some trouble finding a way to check this so if you know of a better and more obvious way to do the check then that would be great.

Comment on lines 359 to 361
if (commandInfoArray[0].CommandType == CommandTypes.Application
|| importedModules.Count == 1
|| moduleCount < 2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can you please explain this check too? EspeciallymoduleCount < 2.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It's to check if the short name for the command can be used. If the first element is an application then we know there's no conflicting commands/aliases (because of the command precedence in PS).
If there's just 1 module imported then the short name refers to that module (and it will be the first element in the list) and of course if there's less than 2 unique modules exporting that command then we can use the short name because it can only refer to that module.

if (commandInfo.CommandType == CommandTypes.Application)
{
endResults.Add(GetCommandNameCompletionResult(commandInfo.Definition, commandInfo, addAmpersandIfNecessary, quote));
results.Add(GetCommandNameCompletionResult(commandInfo.Definition, commandInfo, addAmpersandIfNecessary, quote));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Hmm, you are not usingendResults anymore, meaning that you are not putting all the module-name-prefixed results at the end. Can you confirm if that expected and why? Also, if it's expected, you should remove theendResults declaration above and the use of it below.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yes that's intentional. It seemed weird to move commands with the same name far apart from each other so the user has to tab through the entire list to find the command alternatives. For example if I want the VMWare version ofGet-VMHost and I type inGet-VMH<Tab> and end up with the Hyper-V version, why shouldn't the next result then be the VMWare version?

MartinGC94and others added3 commitsJune 18, 2024 10:54
Co-authored-by: Dongbo Wang <dongbow@microsoft.com>
Add comments.Remove unused list.
@iSazonov
Copy link
Collaborator

If PSRL remove the duplicates itself why do we need remove them in Engine? I guess it could be useful sometimes to see all options.

@microsoft-github-policy-servicemicrosoft-github-policy-servicebot removed the Review - NeededThe PR is being reviewed labelFeb 26, 2025
@MartinGC94
Copy link
ContributorAuthor

PowerShell is also used in editors where the editors may or may not remove duplicates. The PSReadLine duplicate removal logic was flawed and was removed here:PowerShell/PSReadLine#3897 though in the latest PowerShell preview it still seems to deduplicate...

Anyway, regardless of what PSReadLine does, the duplicate results aren't useful because the completion text is exactly the same as you can see in the example in the PR description. Module qualified commands will still be shown as needed.

@iSazonov
Copy link
Collaborator

@daxian-dbw@andyleejordan I'd want to get a confirmation that it is a right change.

@iSazonoviSazonov added the CL-GeneralIndicates that a PR should be marked as a general cmdlet change in the Change Log labelMar 3, 2025
@iSazonoviSazonov self-assigned thisMar 3, 2025
@iSazonov
Copy link
Collaborator

/azp run

@azure-pipelinesAzure Pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

{
var commandInfo = commandList[0] as CommandInfo;
if (commandInfo != null && !string.IsNullOrEmpty(commandInfo.Prefix))
var commandInfo = (CommandInfo)commandList[i];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It seems there can bestring.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

In what scenario though?MakeCommandsUnique is only called in one place using thecommandInfos received from runningGet-Command with some predefined parameters. These parameters always result in a CommandInfo.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't know a scenario but I see line 308 and then line 315.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I looked at the code forGet-Command. It seems the only scenario where it outputs strings is if you use theSyntax parameter, which we don't do here. So the string handling is either becauseGet-Command used to have some other scenario where it would output strings, or a mistake/misunderstanding in the original completion implementation. Either way there's no reason for the new code to try and handle strings.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Sorry, I don't think about handling the strings. I have concern about throwing. So suggestion is to useas and check for not null. Since we ignore all exceptions in the file it is more reliable.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

But if there's no scenario where it would be a string then there's no way it would ever throw? I mean you wouldn't suggest to add a null check for:var x = 1; if (x == 1) {} because there's no scenario where it can happen, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The important thing is that the code abovecan create a string and we will get an exception. The fact that this method is used so that there can be no strings does not guarantee that this will not change in the future.Every change must be reliable. If you clean the code above later, you can remove this check. But it should be reliable now.

MartinGC94 reacted with thumbs up emoji
@iSazonov

This comment was marked as outdated.

@azure-pipelinesAzure Pipelines

This comment was marked as outdated.

@iSazonoviSazonovenabled auto-merge (squash)March 4, 2025 12:31
@iSazonoviSazonov merged commit6661f6f intoPowerShell:masterMar 4, 2025
38 of 40 checks passed
@microsoft-github-policy-serviceMicrosoft GitHub Policy Service
Copy link
Contributor

microsoft-github-policy-servicebot commentedMar 4, 2025•
edited by unfurl-linksbot
Loading

📣 Hey@MartinGC94, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗https://aka.ms/PSRepoFeedback

@MartinGC94MartinGC94 deleted the DontIncludeDuplicateCmdResults branchMarch 4, 2025 13:49
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@blaisemGHblaisemGHblaisemGH left review comments

@iSazonoviSazonoviSazonov approved these changes

@daxian-dbwdaxian-dbwAwaiting requested review from daxian-dbw

@andyleejordanandyleejordanAwaiting requested review from andyleejordan

Assignees

@iSazonoviSazonov

Labels
CL-GeneralIndicates that a PR should be marked as a general cmdlet change in the Change LogSmall
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Tab-completion fails for commands with the same name from different modules
4 participants
@MartinGC94@iSazonov@daxian-dbw@blaisemGH
[8]ページ先頭
©2009-2025 Movatter.jp