- Typed object streams, which gives you stuff like autocomplete, IDE support, and generally there's no need to muck about with sed/awk/xargs - Very fast, it's absolutely fine to read a file line by line, and parse it in a script, whereas doing the same in bash/awk is a ton slower than clever use of cat/grep/wc (and a myriad of other tools) - Due to type information being retained, it's a lot easier to figure out what a given script does, without having to know how the output of a given tool looks like, given it's particular command line switches.
This is just my opinion, but PowerShell is a lot more geared toward people like me, who only write a script once in a blue moon/muck about with the build scripts occasionally, while Bash is more geared toward veteran sysadmins who live and breathe this stuff.
Or it follows the opposite mentality and the sell comes with batteries included?
I'm thinking of some arbitrary example, like downloading a JSON and parsing it to obtain some nested sub-property. In Bash world you would use the shell to execute at least something like `wget` to do the download part, and then run `jq` to parse the JSON and select the desired property. Both of `wget` and `jq` are independent programs, installed separately, with their own input & output channels, that you combine together by using the shell itself.
How would this work with PowerShell? (feel free to use some other example that might be better suited)
powershell offers cmdlets which let you sort and filter these result objects based on object property values rather than sorting on plain text values.
Obviously when printing to stdout or stderr, THAT bit is plain text, but until that very last step of displaying in the terminal, powershell results are objects.
So, that gives you a form of type safety, which isn't strictly possible in text-only shells. Powershell uses reflection to inspect the objects since the exact type of a response may have never been seen before. You can write your own cmdlets which return your own types and you can modify types returned by cmdlets using operators like 'select'. So, it's type-safe but not like everyone is used to. Powershell cmdlets always return objects (or errors, I guess), but the structure of those objects isn't always known until runtime. You can still use those never-before-seen types with the standard operators like sort and select, too.
Powershell also offers output conversion cmdlets which let you output to CSV or a textual table or a list, which is helpful when the next step in your pipe chain is a tool that expects textual input or a csv file. One can also write their own output formatters, of course.
In those ways, powershell and nushell appear to have the same goals. I haven't looked at nushell any more closely than it would take to notice this, so there may be other similarities I haven't noticed, yet. I'm sure there are many differences that I haven't noticed yet, as well.
Regarding the objects themselves, the way you describe them makes me think of Javascript objects & arrays: you don't need to know the exact shape of an input object, as long as it has the specific properties that you want to work on. Same for arrays: regardless of their content, the language allows you to use the standard ops like map() or find() (and it's then a matter of you providing adequate functions to access the contained elements)
To download json over rest you would use Invoke-RestMethod or irm.
To convert json to objects you would use ConvertFrom-Json.
To select properties from objects you would use Select-Object or select.
Here is a concrete example that I wrote for the rustlings install script: https://github.com/rust-lang/rustlings/blob/main/install.ps1...
Note that I used Invoke-WebRequest instead of irm here.
If ConvertFrom-Json & Select-Object were not builtin, how much information about each other would they need to cooperate? Can an unrelated change in ConvertFrom-Json's output break corresponding Select-Object command? How much are they intertangled?
To your point, all cmdlets adhere to an interface so they always return and receive typed data. They don’t really need to know anything except that they’re receiving or giving powershell objects.
Non built in commands (native binaries) just pipe a stream of bytes just like any posix shell.
Select-Object (in this instance) selects a property from the object.
An unrelated change in ConvertFrom-Json wouldn't change it's basic nature which is to convert json into something you can manipulate with other PowerShell cmdlets.
I really like the consistency that those commands have: ConvertFrom-<ConverterFormat>.
No built in converter for the format you need? I'm just speculating here, but I guess you just need to implement this or that Interface and there you go.
You can also just write a function in your profile.
[0] https://docs.microsoft.com/en-us/powershell/scripting/develo...
On linux...it seems both redundant and just plain weird for weirds sake. There are literally dozens of alternatives on linux that have a sane syntax and are likely preinstalled.
It's not a good interactive shell environment though. The commands are way too verbose and the syntax feels clunky for keying in.
[0] tab complete works on cmdlets, switches, and variables.
Same for switches and parameters. You don't have to miss `rm -rf foo/`, it's just `ri -re -fo foo/`
The module system is also not great for distributing little configure snippets like Oh My Zsh or something, it's clunky and over-complicated for that.
Isn't this how modern tab complete works everywhere? bash 5.1 (the shell I happen to be running right now, and which I mention because I think of its out-of-box tab completion as pretty basic) tab completes variables.
We use it for automation in our .NET codebase (which is being developed on both Windows and Linux) instead of bash scripts because of that and the fact it's preinstalled in the .NET SDK Docker images
Quick examples:
- Accelerators for data and conversion tasks. For example, reading a file with `Get-Content` (or frequently in the shell, the alias `gc`) and parsing and converting into a traversable, queryable XML: `[xml]$myXml = gc my-file.xml`. Then you can go `$myXml.customers.firstName` or use an XPath query.
- To get the difference between two dates, `[DateTime]::Now - [DateTime]'2021-01-01'` returns a `TimeSpan` with the elapsed hours, days, etc. It parses the date string for you because of the `[DateTime]` before it.
- The cmdlets for system administration. For example, exporting processes that use more than 200 MB of RAM and their image paths to CSV: `Get-Process | where { $_.WorkingSet -gt 200000000 } | select ProcessName, Path | Export-Csv memory-hogs.csv`
The only PowerShell tool I did love was posh-git [0]. Thankfully, someone has ported it to bash/zsh as posh-git-sh [1].
docker network inspect webservers -f '{{ range.Containers}}{{.IPv4Address}}{{end}}'
Must admit, I am no big fan of ps syntax - too verbose for interactive use - too unfriendly for scripting..
Also if you are managing Azure from Linux or macOS.
The unix way of text streams and tools to manipulate them are too ingrained that I haven't bothered to get in detail, but I hear some people are fans.