Article might be more successful if it demonstrated some of the advantages of PowerShell, such as returning the output as objects instead of lines, and what you can do with them as a result.<p>I'll admit to being in the "Bash is what I know, I'll just install WSL/Cygwin/PuTTY on my Windows workstation and be done with it" crowd. PowerShell is on my bucket list of things I need to learn at some point, or at the very least just get a RosettaCode cheatsheet of common stuff I do in bash and how to do it in PowerShell for when I'm stuck on remote Windows servers.
I dev on a Mac and do a lot of 'quality of life' scripting with Bash. I recently had to do something on a PC and figured I'd try out Powershell. I have to say, it was a joy. Dealing with objects instead of text is so refreshing, it really is a game changer especially when you start integrating with COM (e.g. excel).<p>The only things I found worse:<p>1 - error handling doesnt bubble in the same way. e.g. I can't do an equivalent of `set -e`, or do `cmd && other_cmd`<p>2 - return values are very nuanced. If you don't understand how function statement contribute to the result, you will spend a lot of time debugging odd issues
I think PowerShell doesn’t really compete with Bash, it competes with Python, Perl or the like. And I haven’t found it to be superior in that aspect other than at integration with Windows system stuff.
This is a pretty poor comparison of the two, especially once it gets into the syntax, of which most of the Bash examples are broken in some way.<p>There’s also a lot of just straight errors, such as mentioning “true” and “false” “values” in Bash, which don’t exist—the userland toolset includes “true” and “false” programs that can be used to inject desired exit code status into some logic flow, but there is no real concept of a Boolean type.<p>Overall, if you’re going to provide a rundown of how x and y compare, you should probably give real examples, not just a laundry list of “instead of grep, we use select-string; instead of sed we use -replace”. But <i>how</i> do you use them? I worked with Powershell some over a decade ago, but this article doesn’t give enough info for me to understand what to do with the information it’s providing. And given the errors in describing how Bash works, I’m skeptical that the Powershell examples are syntactically correct either.
The biggest issue in PowerShell is very slow script execution startup time, 300-500ms seems to be typical. So forget about externally launching PowerShell scripts thousands of times.<p>The second biggest issue I've seen is generic lack of robustness and maturity. Default cmdlets do the common case nicely, but once you have something unusual in the mix things go wrong fast... By unusual, I mean things like filesystem junctions, volumes mounted into directories.<p>If you want colors, Write-Host is nice. Except that it goes only to console AND to (undocumented?) file id 6! (same way like stdout goes to 1, stderr to 2, etc.).<p>PowerShell seems to behave slightly differently in each Windows version. A script that's written for Win10 1803 might just break under 1809.<p>I don't have much issues with Bash etc., even sh. It performs well and is very robust. I do hate its many footguns, like how easy it is to get escaping wrong.
@vedipen, thera's a typo in bash "if" example, an if-block is closed with "fi".<p>edit: "if" example also misses a semicolon before "then".
There are so many errors in his bash code, it makes you doubt the author's basic bash competence. None of his examples use fully correct bash syntax.
Just going to leave this here:<p>Known Issues for PowerShell on Non-Windows Platforms<p><a href="https://docs.microsoft.com/en-us/powershell/scripting/whats-new/known-issues-ps6?view=powershell-7" rel="nofollow">https://docs.microsoft.com/en-us/powershell/scripting/whats-...</a>
I use PowerShell for quite some time (mostly windows/.NET guy here) and it would be great tool except one thing: the amount of not obvious quirks is astounding and not really decreased over the years. Probably because of avoidance of breaking changes, which is understandable where there are tons on powershell scripts out there. But for for someone who uses it mostly as a shell to write one liners or occasionally write a script not longer than 30 lines of code, it's really discouraging when you encounter again some unexpected behavior (even though you thought you learned powershell "good enoguht" couple years ago).
Having used both, in a personal and professional capacity, I don't think they occupy the same "real estate". If you have a bunch of Windows systems to admin, sure, PowerShell works great with all the Windows built-ins. In fact, it works with SCCM pretty well. If your systems are Linux-based, you can use shell scripts to interface with something like Chef or Rundeck. Use something that works natively and is designed for the platform you need to orchestrate.
The real difference is: in any reasonable bash script there will be a significant amount of awk, cut, tr and other commands to munge the output of one command into the input expected by the next. In PowerShell that totally goes away.