Re: Like grep? sed? awk?
>>"These are my show-stoppers, but I might just be doing it wrong, so please correct me."
Well I'm far from an expert with Powershell, I'm actually more familiar with Bash. But I'll take a stab at one of the issues you raise:
>>You can only use the awful build-in console Window, which is awkward to resize, text selection doesn't handle wrapped lines, can't access it remotely (as a shell) unless you RDP to it, and can't redirect the output. Mid-line tab completion removes the rest of the line. Tab completion-enumeration and line history isn't to my taste. It's worse than “php -a”, and nobody does that
I have good news - you're doing it wrong. ;) Fire up powershell Integrated Scripting Environment. This is built into Windows. If you don't have a shortcut to it, just type ise from the standard Powershell commandline and it will launch. This is what it looks like:
It has built in debugger, script editing pane, auto-complete, command reference, etc.
Remote access to the shell is perfectly possible and doesn't require RDP. It's sort of kind of a wrong question. There's no particular reason why you would need to run Powershell "on" the remote computer instead of running it locally and simply executing remote commands on that computer. Assuming you have credentials and the remote computer is configured to allow remote Powershell commands, you can just start a remote session from your local shell and security is more or less just an SSH equivalent.
However, if you DO want to run "on" the remote box, you can do that without RDP. IIS has a plugin which allows you to invoke Powershell commands. It's called Powershell Web Access (PWA), runs over HTTPS so it's firewall-friendly. But I think remote sessions are the normal way to do things (like I say, I'm not an expert on this).
I'm honestly, not sure what you mean by "can't redirect the output". If you mean just redirecting things to places other than stdout, it does that anyway. The only reason something ends up on the screen is if you don't give it anywhere else to in which case output is just passed to a cmdlet called something like "default", iirc. If you're talking about redirecting error output, Powershell raises errors as exceptions which you can handle how you wish. If I've misunderstood what you're asking, apologies.
>>"Powershell's passing of objects only works with cmdlets, so you're restricted to .NET languages if you want to create your own commands for the object streams to be of any use, whereas the 3 standard text streams are available to any process regardless of language - and can be stored for later use (> out.txt), copy+pasted, etc"
I'm a little confused by this one. To take the last point first, you absolutely can output or store anything from Powershell in textual format if you wish. You can just pipe something to ConvertTo-Json, ConvertTo-Xml or even just simple strings if you really wish.
Regarding the .NET issue, it does work in a .NET environment, yes. That's not a problem for its target Windows environment and you can use .NET on GNU/Linux if you wish. Whether or not that is an issue for you depends on your environment and what you want to achieve. It might be, it might not. I'm just here to shoot down stupid arguments, really.