I'm not sure I understand your point regarding having to look at the output of commands to know how to use them. At least with Powershell you have tab-completion suggesting your object members; 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 (and the semantics of what you're looking at are not discoverable, so you're likely to have to some API digging of your own). 'cut' and the like is sadly fragile for a number of reasons, and you generally won't discover them in advance (e.g. when the date "field" starts containing a year, sizes overflow or start being indicated with human-readable abbreviations after a threshold, which is exactly the sort of thing you can't tell by inspection). And bash's failure modes are really sharp.
To be honest, something like
$titled = gci *.md| ?{ (gc $_)[0] -like '# *' }
seems short and less error-prone than the bash equivalent. Not sure what it would be. Something like
titled=(); for file in *.md; do if head -1 "${file}" | grep -sq '^# .*'; then titled+=("${file}"); fi; done
I think there's a lot of little gotchas in there, and not a little "API digging" for options, though it's simple in concept.
> 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.
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.
To be honest, something like
seems short and less error-prone than the bash equivalent. Not sure what it would be. Something like I think there's a lot of little gotchas in there, and not a little "API digging" for options, though it's simple in concept.