Check out powershell
It was made by people who don't know how to use existing tools and what the actual problems are. It's like people who keep creating "new" text editors, but they never learned well how to use existing ones. So they end up with crippled half-baked thing that's some concept from the 80s that was discovered to be a dead-end in the 90s, but with modern cosmetics.
PowerShell is just incompetence and hubris of people working for a large company which can push their random garbage software on a lot of users and developers due to having huge market presence.
(curl http://localhost:5555/log | grep -o -E "2025[0-9-]+")
(Invoke-WebRequest -Uri "http://localhost:5555/log" -UseBasicParsing).Content | Select-String -Pattern "2025[0-9-]+" -AllMatches | ForEach-Object { $_.Matches.Value }
Get-Process | Where-Object { $_.ProcessName -match "ffmpeg" }
Auto complete is quite good though.
$ ps ax | grep ffmpeg
66898 pe S+p 0:00.01 grep ffmpeg
$ ps ax | grep '[f]fmpeg'
$ pgrep ffmpeg
$
The way to write that on the command line Powershell would be:
ps ffmpeg
It also has positional parameters meaning you don't have to specify parameter names, though you might as well because tab completion is a thing. And if you're really keen on not using tab completion, it autocompletes parameter names for you meaning "get-help man -e" is equivalent to "get-help man -examples".
Here are less verbose posh commands for your examples.
(curl http://localhost:555/log -useb | select content | sls "2025[0-9-]+" -a).select.matches
(gps ffmpeg) or (ps ffmpeg)
Edit:
I should have added, curl ships with Windows now so a farer comparison would be a select-string on curl.exe.
We want modern (and by that they mean C#-like) programming language in shell. We want user types, type checking, structured, modular code.
And they forget that the reason Unix shell is easy in some respects is precisely because it has none of that. Since everything is text, serialization is trivial. But serialization is vital if you need to work remotely between different shells.
Structure will require a lot more operations for composing and decomposing it in order to transmit messages. Equality and identity become a problem.
Custom types are similar to structure, but on top of it present a problem with serialization (somehow both shells need to have same type definitions, and what happens if they inevitably don't).
The problems above not being addressed... what you get is another "scripting" language, of which there are already dozens, with no special benefits when it comes to it being used as shell, but with some problems. Just not worth it and illustrates lack of research and understanding of the problem space on the part of the authors.
Serialization is trivial in PowerShell but also much more powerful because you can pipe the output of any command to ConvertTo-JSON or ConvertTo-CliXML which gives you very nice STRUCTURED serialization that is much easier to consume.
There isn't really. For a lot of PowerShell objects, there's no way of converting them to JSON or XML. Imagine what happens if you convert a closure to JSON? It doesn't matter what language you use, it's always going to be a problem.
You are simply too inexperienced with the subject to be able to have a judgement on how (well) it works.
Trust me, it's anything but "trivial".
objects are piped instead of text. This single change makes a ridiculously huge improvement. You are no longer forced to perform incredibly tedious and fragile text manipulation. This also enables filtering on property names and the ConvertTo-JSON command which is amazingly useful.