This PR has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 10 days.
Thank you for your contributions.
Community members are welcome to grab these works.

Steve Lee (@SteveL-MSFT) do we have interest in the change?

Ilya (@iSazonov) yes, I think this change is something we want

kwkam Please rebase to pass CIs.

Ilya (@iSazonov) OK, rebased to latest master.

but not if it contains valid wildcard characters.

Does the comment only refer to this method or its use too?

Does the comment only refer to this method or its use too?

The comment only applies to the method, not to its uses. If a caller assumes differently, then another method should be added for checking if a path contains valid wildcard characters.

I think the breaking change is in gray area because using of the method implies that we want exactly working wildcards and not something similar ']['. Also I'd said that passing '][' in the method is a bug.

Ilya (@iSazonov) This is more of a unacceptable changes in public contract. Quoted from the breaking-chagne-doc:

A code change that results in a change to the existing behavior observed for a given input with an API, protocol or the PowerShell language.

That being said, I do like the refactoring changes in CommandSearcher.cs and inclined to keep it.

Add the "Review-Committee" label.
To @PowerShell/powershell-committee: This PR proposes a behavior change to the public method WildcardPattern.ContainsWildcardCharacters(string pattern). Currently, ContainsWildcardCharacters(string pattern) only checks if the string contains any wildcard characters. The proposed change is to make it check for valid wildcard patterns. That means, for the string [abc or ][abc, currently the method returns true and it would return false with the change.

The proposed change is a breaking change that falls in bucket 1, so we need committee to review.

@PowerShell/powershell-committee reviewed this. Recommendation is to deprecate this api and introduce ContainsValidWildcardPattern() API and fix all callsites to use the new method (separate PR).

Should the new method be a strict checking (e.g. try/catch with the WildcardPatternParser::Parse)?

At first glance it should be TryParse(). Although we should review all callsites (131) - huge work!

The method ContainsWildcardCharacters is called at many places in powershell, and I believe at least some of the callers only need a hint about whether a string might contains wildcard pattern, instead of an accurate answer, so for those caller, a perf penalty will be charged as [WildcardPatternParser]::Parse is relatively expensive.

Even for the callers that do want the accurate answer, another call to Parse will be made when creating/using the WildcardPattern from the string, so we will be paying the tax twice.

We can still add the new method ContainsValidWildcardPattern wrapping a call to WildcardPatternParser.Parse, so we can accurately know if a string contains valid wildcard patterns. But it's probably not right to blindly change all callers of ContainsWildcardCharacters to the new method.

kwkam Changes regarding ContainsValidWildcardPattern and ContainsWildcardCharacters would be a bit tricky and likely involve many changes in other places. How about we revert the changes to ContainsValidWildcardPattern in this PR and make it only about the refactoring changes in CommandSearcher.cs? We can merge the refactoring changes, and open a separate issue/PR to discuss the right fix for ContainsValidWildcardPattern.

I full agree with Dongbo Wang (@daxian-dbw).

kwkam Do you agree with Dongbo Wang (@daxian-dbw) suggestion to split the PR?

rebased PR

PoshChan-Bot (@PoshChan) Please remind me in 1 hour

Travis Plunk (@TravisEz13), this is the reminder you requested 1 hour ago

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Dongbo Wang (@daxian-dbw) Please update your review

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Dongbo Wang (@daxian-dbw) Please update your review

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

This PR has 36 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Small
Size       : +33 -3
Percentile : 14.4%

Total files changed: 4

Change summary by file extension:
.cs : +27 -3
.ps1 : +6 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

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 the context 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 the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.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.

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 15 days. It will be closed if no further activity occurs within 10 days of this comment.