You can keep it. I'll stick with zsh or bash.
It is always an object. Strings, arrays, paths, the registry—everything can be manipulated as an object.
Ah yes. Bash, and its highly intuitive `if /usr/bin/\[ 5 -eq "5" ']'; then :; fi` comparison operators.
I get that when everything is text, it becomes simpler to reason about. But you also have to do a lot of maneuvering to get information out of it. PS tries to give you more power.
My main gripe with ps is command discoverability: I don't know who thought that the "verb-subject" would be a good idea, because if I type "get-" and tab to auto complete, how the hell will I find the command about networking I want?
The learning curve also sucks, but I don't think it's worse than bash. I do remember spending six months with a bash manual tab open in my desktop back when I was starting Linux development.
There are also other crazy advantages ps have over bash, like the native ability to understand cmdlets and their parameters, powerful scripting capabilities with decent support for loops, conditionals etc.
And I don't event know what to tell you about the operators... They were copied from POSIX, so complaing about then is complaing about bash & co.
Finally, PowerShell also let's you access all of the dotnet namespace. This allows you to do a lot of stuff, because you would literally be programing instead of scripting.
The answer is the origins of how Windows handles everything. It diverged every time a new hire took over a subsystem. "Not invented by me" ran strong in those days.
try this PS script out
clear
function Get-Strings1 {
@('hello')
}
function Get-Strings2 {
@('hello', 'world!')
}
(Get-Strings1).Length
(Get-Strings2).Length
5
2
and you'll watch different features crash into each other in bizarre ways. For example, everything is an object but if that's the case how do you output log statements to the console since it's also a shell?
PS is hosted, the default PS host will print out whatever reaches the "top". Think of your PS code as the "first function" with it's own set of returns. The host will print out whatever your code "returns", but this is consistent all the way down the chain.
clear
function Get-Strings3 {
(Do-Stuff)
return 'hello'
}
function Do-Stuff {
Write-Output 'haha'
}
(Get-Strings3).Length
2
(Do-Stuff) | Out-Null # throws away anything coming out of the function call
And consider what we've demonstrated here. That PS will happily remove arrays based upon runtime state and happily add them based upon runtime state.
If you're confused about why this still happens even though this version uses the return keyword, remember it's PS which means any silly, preconceived notions you have are out the window.
returns does two things.
1. Write-Output
2. Ends execution of the function
If you remove the return keyword it will have the exact behavior it did previously because it's the last statement in the function. And yes, that's how easy it is to accidentally write something to the output and thus turn your return value into an array.
Since I'm on a roll, 1 last example.
clear
$arr = @($null, 'hello')
$isNull = $arr -eq $null
$isNull.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Object[] System.Array
You see, PS has been lying to you all this time, arrays in PS aren't arrays. They're wrapper objects that pretend to be an array to give all sorts of cool magic. One of those magic things being it's propensity to forward function calls on the array wrapper to the elements themselves.
What it's actually doing is calling -eq on each element (think LINQ select) and returning a new array.
Which is useful, you can imagine having a list of COM objects with a name property, you can do a select on the name by just doing ".name" on the array wrapper itself. It has its uses.
BUT
you can't do that for any properties that are on the array (such as Length). Also, PS allows you to attach functions to objects at runtime, if you were truly evil you could attach a myriad of functions to an array object you handed back and laugh as the poor suckers using your code can't understand why calling .Name doesn't forward like it should.
----
I could go on and on and on about PS. I once built a VPS automation solution in PS. My (naive) thinking at the time was that the remoting capabilities for windows was useful so I may as well build it out in powershell. I maintained that solution for 5 years, 4.5 years in and I was _still_ getting surprised by interactions w/i PS.
Here's an exercise for the reader.
write a function that will successfully test an input parameter against null for everything. There's a solution.
My issue with powershell is that it isn't really a shell language, or rather, not a tty language. I do think it's way better than bash, but I do not want to use it like bash, I want to use it like AWK, but for my system. I want it to use it only in scripts, or with an exec in a command line at worst. I think bash have better built-in for ttys, and is faster/more reactive (that might be my windows config but I don't think so).
I want to navigate with bash, and script with powershell (which I do to be completely honest, but I'd like to do that in a windows terminal and not wsl).
Why? There is PowerShell, able to run on Linux and MacOS. And compared to Bash it is actually readable language.