Adds an OnlyMatching parameter to Select-String to return only the string that matches the pattern

[nanyiyang]

PR Summary

Part of HackIllinois with @TylerLeonhardt and @rjmholt
Added an OnlyMatching parameter to Select-String with similar behavior to grep -o. Also made OnlyMatching parameter to work with AllMatches.

PR Context

Resolves #7712.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
    • Add [feature] to your commit messages if the change is significant or affects feature tests

[msftclas]

All CLA requirements met.

[vexx32]

A couple of small things I think should probably be fixed, but otherwise solid work from what I can see. 👌

[vexx32]

This is a bit unclear, as Select-String already returns data containing the specified characters. Does this parameter affect the search or the result that the user sees or receives?

[nanyiyang]

Sorry, the parameter should be affecting the result that the user sees. I will update the comment and re-commit.

[rjmholt]

Worth noting that this causes a string rather than a MatchInfo to be returned

[TylerLeonhardt]

How does this change work with -AllMatches?

I'd probably expect something like this:

PS > "asdf 123 asdf" | Select-String \d -OnlyMatching -AllMatches
1
2
3

[powercode]

Is this really a change we want to make?
The same result can be accomplished on the command line with | % Line, right?

The *nix commands has lots of flags to change the output format of commands, but this is generally not needed in PowerShell since we have structured objects in the pipeline.

Tab completion will have to be fixed, since this parameter changes the output type.

Can you help me with a scenario where this is change is compelling?

[TylerLeonhardt]

I want to ping @mklement0 to get his thoughts but @powercode I don't think that accomplishes the same goal.

Line gives you the whole line. We want to only get the matching parts of the line.

[powercode]

Update-TypeData -Typename Microsoft.PowerShell.Commands.MatchInfo -MemberName MatchingText`
  -MemberType ScriptProperty -Value {foreach($m in $this.Matches){foreach($g in $m.Groups){$g.Value}}}

Then

sls … | foreach MatchingText

[mklement0]

@powercode:

The same result can be accomplished on the command line with | % Line, right?

Supporting returning whole lines directly is the subject of #7713 - and both it and the change at hand (matching parts only, via #7712) have been green-lit.

The motivation is the same in both cases:

• Convenience and semantic directness: Wanting just strings (whether in full or just the matched parts) strikes me as the typical use case (not least because the cmdlet's name is Select-*String*) - see Add a switch to Select-String that makes it return just strings for convenience and performance #7713 (comment)

• Performance: See Add a switch to Select-String that makes it return just strings for convenience and performance #7713 (comment)

[TylerLeonhardt]

@powercode I can get behind that. We can add another property to MatchInfo called MatchingText and then do:

Select-String "foo" | foreach MatchingText

like you said to get this behavior.

For context to @nanyiyang...

Select-String "foo"

returns a collection of MatchInfo, right? By adding a property called MatchingText to that we can use the ForEach-Object or foreach or % command:

Select-String "foo" | foreach MatchingText

which says, give me just the MatchingText in each of these objects. This would achieve what we want to achieve.

[mklement0]

@TylerLeonhardt:

That is only slightly less verbose than what you have to do currently:

# Works with -AllMatches too
PS> 'afoobar' | Select-String 'foo' | foreach { $_.Matches.Value }
foo

and wouldn't yield the hoped-for performance improvements - though I suppose it could be implemented as well (though I personally think -OnlyMatching is sufficient).

Also note that .MatchingText, if implemented as a property of [Microsoft.PowerShell.Commands.MatchInfo], would have to be an array to accommodate the
-AllMatches case.

[TylerLeonhardt]

Good catch... I feel like in both #7713 and #7712 you're really asking for a different object to be returned by Select-String.

One that doesn't contain the extra fluff for an increase in performance?

[mklement0]

Specifically, I'm asking for strings to be returned - which is arguably Select-Strings's core mandate.

Not having fluff, i.e. not having to access properties in a subsequent step when all you're looking for is strings not only improves performance, but is also concise and convenient.

[mklement0]

I've summed up the rationale for this new switch as well as for -Raw in #8962 (comment); given that this new switch was approved in #7712, I suggest you voice any objections there.

[stale]

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.

[stale]

This PR has been automatically closed because it is stale. If you wish to continue working on the PR, please first update the PR, then reopen it.
Thanks again for your contribution.
Community members are welcome to grab these works.