For the most part, I’ve found it very hard to care about PowerShell. But as time goes on, I mostly look at it with the thought, “Wish I had more use for that”.
Things that I do that require some scripting, and that run on more than unix systems, usually resort to creating .cmd or .bat files to handle the Windows systems. There’s mostly two reasons for that: execution policies and portability.
I don’t really like scripting cmd.exe. As an interactive shell, it’s barely livable but gets the job done. The focus on interactive mode, and the nature of DOS, show through in what can be done in cmd.exe. NT’s modern extensions and so on make it a lot better than COMMAND.COM but cmd.exe is not a good scripting environment, nor a great interactive shell: it just sucks less than its predecessors.
PowerShell on the other hand took some good ideas and largely addressed much of the suck. Exposing .NET even offers the opportunity to solve problems that would call for writing a solution in something beyond bash/ksh, or finding dedicated utilities for. It is really neat the amount of shit you can do in a PowerShell script.
But in the end, the default execution policy is what really keeps me away. Open sourcing and cross platformyness stuff in Core 6.x resolved most of my negative feelings for PowerShell, but it doesn’t suit my scripting needs.
By default: client systems reject running PowerShell scripts, and so monkeying with execution policy is needed. Either to unrestrict it for the current session or my user. Which makes using it for projects less useful than using the older comspec. Because while cmd.exe is very meh, it doesn’t require any extra monkeying after I’ve git cloned my repo. Yet another thing to do when setting up a system, or document about a code base, that I don’t need.