1

Problem

I'm trying to find a way to find a string in a object list, like the result of Get-Alias. My problem is that all solutions are either way too long to be practical to use or do not result in the behavior I need.

What I've tried so far:

Using alias | sls -All "Get-". No result, because sls uses toString which is only the name column:

enter image description here

  1. Using alias | Out-String | sls -All "Get-". Only highlights

enter image description here

  1. Using alias | Where-Object {$_.Definition -like "*Get-Alias*"}. A lot to write and requires knowing the column where the text is.

enter image description here

  1. Using alias | findstr "Get-". Works, but requires the use of a legacy executable that is not available on all PowerShell Core supported platforms. I want the code to work on all platforms without switches.

enter image description here

  1. Write to a file and then pipe that to Select-String. Very inpractical.

...

Can someone help me with this problem?

Dmitrij Drandarov
  • 67
  • 1
  • 5

1 Answers1

4

You want to grep the objects as you see them displayed on your console, your first example using Out-String was going in the right direction except you were missing the -Stream switch:

alias | Out-String -Stream | sls -All "Get-"

Or if you want to have it shorter, you can use the built-in wrapper oss:

alias | oss | sls -All "Get-"
Santiago Squarzon
  • 41,465
  • 5
  • 14
  • 37
  • 1
    Off topic, but it's funny where you placed your winter hat haha – Abraham Zinala Dec 15 '22 at 17:48
  • 1
    @AbrahamZinala LOL not sure where else it could go :D – Santiago Squarzon Dec 15 '22 at 17:49
  • 1
    It's just funny seeing a fish with one xD – Abraham Zinala Dec 15 '22 at 17:50
  • 2
    Nice; Worth pointing out that that `oss` arguably shouldn't be necessary, and that `Select-String` should _by default_ use the richly formatted string representation rather than the `.ToString()` value for non-string input objects, as suggested in [GitHub issue #10726](https://github.com/PowerShell/PowerShell/issues/10726). – mklement0 Dec 15 '22 at 18:43
  • @mklement0 ah yes I've seen this issue before. tbh I don't know if I agree, I don't really have an opinion on this topic as I believe it is the wrong tool to filter objects. I don't know which implications this could have if `Select-String` defaults to this. Building a proxy command that does this by default is also an easy alternative for anyone wanting to do this. – Santiago Squarzon Dec 15 '22 at 19:01
  • 1
    @mklement0 Thanks for pointing to that issue. It has some great suggestions :) – Dmitrij Drandarov Dec 15 '22 at 19:02
  • @SantiagoSquarzon, yes, `Select-String` is the wrong tool for _robustly_ filtering of objects _for programmatic use_. However, it _is_ the right tool for _quick-and-dirty_, _interactive_ use, and indeed I have a wrapper function for personal use that has become an indispensable tool for me. There's no reason _not_ to fix `Select-String` to work this way, given that (a) it is what users intuitively expect and (b) the current behavior is useless. Using Dmitrij's example: if `Select-String` worked that way, `get-alias | sls get-` would be a handy way to quickly view the aliases of interest. – mklement0 Dec 15 '22 at 19:13
  • this minor change would break things for folks using it the way it was designed, i.e.: `[Text.StringBuilder]::new('hello world') | sls hello` would no longer work. Not saying it's a bad idea but things like this need to be thought carefully imo moreso when the fix is adding a new command or having a wrapper... @mklement0 – Santiago Squarzon Dec 15 '22 at 19:48
  • Fair point: that's an edge case that would break. `Select-String` is indeed designed for _strings_, as the name implies. But that doesn't mean that `.ToString()` is the right way to stringify non-string input. In fact, it is almost always unhelpful. To my mind, this change is a clear-cut [bucket 3](https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md#bucket-3-unlikely-grey-area) change, even more so given that the use case at hand is to be avoided _in scripts_. – mklement0 Dec 15 '22 at 19:55