使用 PowerShell sls (Select-String) vs grep vs findstr

Question

Could someone clarify how sls (Select-String) works compared to grep and findstr?

grep: grep <pattern> files.txt

sls: sls <pattern> files.txt (default parameter position for sls is pattern then file)

grep examples: grep "search text" *.log ; cat *.log | grep "search text"

sls examples: sls "search text" *.log ; cat *.log | grep "search text"

As an aside, all PowerShell Cmdlets are case-insensitive, unlike Linux tools which are generally always case-sensitive but also older tools like findstr which are case sensitive too, but findstr can be used in PowerShell, and works in situations where sls does not, for example: Get-Service | findstr "Sec" Get-Service | findstr "Sec" (this works without a problem!), but when we try to use sls in a similar way Get-Service | sls "Sec" Get-Service | sls "Sec" we get nothing (presumably this fails because sls works with strings, but Get-Service returns an object, so that's understandable - but what is findstr doing then in that it can see the output as a string?).

So, my thinking is "ok, I need to make the output from Get-Service into a string to work with PowerShell Cmdlets", but that doesn't work (or not in a way that I would expect):

Get-Service | Out-String | sls "Sec" Get-Service | Out-String | sls "Sec" (gives results, but odd)

(Get-Service).ToString() | sls "Sec" (Get-Service).ToString() | sls "Sec" (.ToString() just returns "System.Object[]")

How in general should I turn an object into a string so that it can manipulate the information (in the same way that Get-Service | findstr "Sec" can do so easily)?

Would appreciate if someone could clarify how things fit together in the above so that I can make more use of sls. In particular, Get-Service | Out-String | sls "Sec" Get-Service | Out-String | sls "Sec" Get-Service | Out-String | sls "Sec" does return stuff, just not the stuff I was expecting (is it searching for each character of "s" and "e" and "c" so is returning lots - that would not be very intuitive if so in my opinion)?

Answer 1

When you use Out-String by default, it turns the piped input object (an array of service objects in this case) into a single string. Luckily, the -Stream switch allows each line to be output as a single string instead. Regarding case-sensitivity, Select-String supports the -CaseSensitive switch.

# For case-insensitive regex match
Get-Service | Out-String -Stream | Select-String "Sec"

# For case-sensitive regex match
Get-Service | Out-String -Stream | Select-String "Sec" -CaseSensitive

# For case-sensitive non-regex match
Get-Service | Out-String -Stream | Select-String "Sec" -CaseSensitive -SimpleMatch

In either case, Select-String uses regex (use the -SimpleMatch switch to do a string match) to pattern match against each input string and outputs the entire string that matched the pattern. So if you only pipe into it a single string with many lines, then all lines will be returned on a successful match.

Answer 2

To complement AdminOfThings' helpful answer :

• In order to find strings among the lines of the for-display string representations of non-string input objects as they would print to the console you indeed have to pipe to Out-String -Stream , whereas by default, simple .ToString() stringification is applied ^[1] .

  • You shouldn't have to do this manually , however : Select-String should do it implicitly , as suggested in GitHub issue #10726 .

• Curiously, when piping to external programs such as findstr.exe , PowerShell already does apply Out-String -Stream implicitly ; eg:

  • Get-Date 1/1/2019 | findstr January Get-Date 1/1/2019 | findstr January works (in en -based cultures), because it is implicitly the same as
    Get-Date 1/1/2019 | Out-String -Stream | findstr January
  • By contrast, Get-Date 1/1/2019 | Select-String January Get-Date 1/1/2019 | Select-String January is the equivalent of
    (Get-Date 1/1/2019).ToString([cultureinfo]::InvariantCulture) | Select-String January (Get-Date 1/1/2019).ToString([cultureinfo]::InvariantCulture) | Select-String January , and therefore does not work, because the input evaluates to 01/01/2019 00:00:00 .

---

^{[1] More accurately, .psobject.ToString() is called, either as-is, or - if the object's ToString method supports an IFormatProvider -typed argument - as .psobject.ToString([cultureinfo]::InvariantCulture) so as to obtain a culture-invariant representation - see this answer for more information.}