The Case for PowerShell on macOS and Linux(deusinmachina.net)
deusinmachina.net
The Case for PowerShell on macOS and Linux
https://www.deusinmachina.net/p/the-case-for-powershell-on-macos
5 comments
I installed PowerShell on Linux on ChromeOS, and I was immediately disappointed. I have a limited use case where I need to validate very basic Windows scripts. It turns out that PowerShell scripts aren't... portable?! Some very basic Windows cmdlets were rejected from the Linux version. I don't know the details of that, but I was extremely discouraged. Waaaaaay easier to install Git-Bash on Windows.
Linux and macOS only have 273 PowerShell cmdlets available to them. If the Windows scripts are using any of the ones that aren't available they won't work. If you stick to the "portable" cmdlets (the aformentioned 273) it is cross platform. I mention this in the article at the bottom. The amount of PowerShell cmdlets available across macOS and Linux have increased overtime, so it's definitely getting better.
The problem is, some of these missing cmdlets are pretty basic/essential (speaking as a sysadmin), so it's a bit ridiculous that they're still left out. I mean, sure, I could just call the native *nix binary, but then I'd lose out on the objects, which then defeats the whole point of PowerShell. Plus, I'd have to rewrite all my existing scripts/scriptlets/libraries, which kills the portability.
I could write wrappers around the native binaries, or build custom PSCustomObjects on the fly in the pipeline, but I don't want to waste my time doing this, when these cmdlets are all pretty standard on Windows, and we really shouldn't be expected to do Microsoft's work.
For instance, Test-NetConnection, Resolve-DnsName (and other net commands), Register-ScheduledJob (background jobs), Get-Partition (and other disk management stuff), I could go on, but these and a lot of essential cmdlets are missing.
More than that, my biggest issue is that a lot of my favorite modules and scripts that I've been using (from the PowerShell Gallery and other places) don't work, and many of my scripts have dependencies on them - which means I'd have to rewrite them all to make it work, and some of them may never have a hope working in Linux/macOS due to missing .NET libs/Windows APIs.
Basically, PowerShell on non-windows systems is not fun. It's neither here, nor there - ie neither does it provide all the functionally of Windows PowerShell, nor does it fit in like a proper *nix shell, and even then, it doesn't object-ify any popular *nix native binaries, so you lose out on all the object-oriented benefits, unless you spend time writing wrappers or constantly build PSCOs in the pipeline.
At the end of the day, if I've resolved myself to just parse all the text from *nix binaries, then I might as well work in a shell that is a first-class *nix citizen like fish or zsh, which is more suitable for that sort of workflow, instead of working in a confusing shell that's neither here nor there.
I could write wrappers around the native binaries, or build custom PSCustomObjects on the fly in the pipeline, but I don't want to waste my time doing this, when these cmdlets are all pretty standard on Windows, and we really shouldn't be expected to do Microsoft's work.
For instance, Test-NetConnection, Resolve-DnsName (and other net commands), Register-ScheduledJob (background jobs), Get-Partition (and other disk management stuff), I could go on, but these and a lot of essential cmdlets are missing.
More than that, my biggest issue is that a lot of my favorite modules and scripts that I've been using (from the PowerShell Gallery and other places) don't work, and many of my scripts have dependencies on them - which means I'd have to rewrite them all to make it work, and some of them may never have a hope working in Linux/macOS due to missing .NET libs/Windows APIs.
Basically, PowerShell on non-windows systems is not fun. It's neither here, nor there - ie neither does it provide all the functionally of Windows PowerShell, nor does it fit in like a proper *nix shell, and even then, it doesn't object-ify any popular *nix native binaries, so you lose out on all the object-oriented benefits, unless you spend time writing wrappers or constantly build PSCOs in the pipeline.
At the end of the day, if I've resolved myself to just parse all the text from *nix binaries, then I might as well work in a shell that is a first-class *nix citizen like fish or zsh, which is more suitable for that sort of workflow, instead of working in a confusing shell that's neither here nor there.
You equalized shell with the tool orchestrator (well, maybe it is for you). It's much more than that, and while pwsh might be a bit of "here and there" in that domain, it's totally "here" in all other domains.
As one example, pwsh language makes one much more efficient with scripts that are way easier to grasp and a lot shorter.
Your tool support questioning is cherry-picking on some cases - I for example, would never use jq in place of pwsh alternatives which are much more capable and readable. And for some formats like CSV there is really no standard binary on linux AFAIK. People basically jump to python et al. for anything more serious then couple liners.
As one example, pwsh language makes one much more efficient with scripts that are way easier to grasp and a lot shorter.
Your tool support questioning is cherry-picking on some cases - I for example, would never use jq in place of pwsh alternatives which are much more capable and readable. And for some formats like CSV there is really no standard binary on linux AFAIK. People basically jump to python et al. for anything more serious then couple liners.
Well, IIRC, the sticking point was "Get-Acl", which is an integral part of the script, and it's easy to see why it wouldn't be portable.