[tdeck]

> you have to at least look at whatever flavor of semi-parsable text is coming from your command in bash to use cut or awk or whatever on it

Having to parse things is definitely a pain, at least until you get good at it. But the critical thing is that all the output is right there on the screen, and often in a format that's at least somewhat designed to be parsed. In PowerShell you have to go diving through the object hierarchy. That would be OK I guess if things were intuitive and the help and documentation were great but that's often not the case. And often the API semantics are designed for a different language altogether (C#) and the things you have to do to consume the API in PowerShell are ugly.

[lenkite]

Your "diving through object hierarchy" has a _consistent_ command called "Get-Member". Not the same where you need to dive through several hundred text output structures for different commands and/or read man page options. I am sorry, but your statement is factually false.

The simplest technique for analyzing the objects that a command returns is to pipe the output of that command to the Get-Member cmdlet. The Get-Member cmdlet shows you the formal name of the object type and a complete listing of its members.