PowerShell is genuinely good now, and most Linux users won't admit it

At a glance:

• PowerShell has been open‑source and runs natively on Linux and macOS for a decade
• Unlike Bash, PowerShell pipes rich objects instead of plain text, simplifying complex scripts
• In hybrid Windows‑Linux environments PowerShell can call Windows APIs and Linux paths from the same session

Why PowerShell has changed

Korbin, a Linux system administrator who also manages Windows networks, notes that the old perception of PowerShell as a Windows‑only, clunky shell has vanished. Since Microsoft open‑sourced PowerShell in 2016, native binaries are available for most Linux distributions and macOS, receiving regular updates alongside the Windows version. This cross‑platform availability means administrators no longer need a separate Windows box just to run a PowerShell script.

The author admits it took him “longer than I'd like to admit” to appreciate the shift, but once he tried PowerShell for a real‑world task, the benefits became obvious. The object‑oriented pipeline, combined with built‑in error handling and credential management, reduces the amount of boilerplate code that Bash scripts often require.

Object pipeline vs text pipeline

The fundamental technical difference is that PowerShell pipes objects, while Bash pipes strings. In Bash, every command emits raw text, which must then be parsed with tools like grep, sed, or awk. PowerShell, by contrast, passes structured .NET objects along the pipeline, allowing downstream cmdlets to work with properties directly.

For example, filtering processes that exceed 10 % CPU usage looks like this in PowerShell:

Get-Process | Where-Object CPU -gt 10 | Select-Object Name

The equivalent Bash one‑liner is:

ps -eo comm,pcpu | awk '$2 > 10 {print $1}'

Beyond readability, the object model prevents many parsing errors that arise when a command’s output format changes. Complex scripts that involve conditional branching, data transformation, or multi‑step error handling tend to be shorter and more maintainable in PowerShell.

Portability and naming conventions

Bash remains the lingua franca of Unix‑like systems. It ships on every Linux distro, Docker container, and most embedded devices, guaranteeing that a Bash script will run unchanged across environments. PowerShell, while cross‑platform, still requires an explicit installation on non‑Windows hosts, which can be a hurdle for ultra‑lightweight containers or legacy systems.

Korbin also mentions the verb‑noun naming style of PowerShell (Get-ChildItem, Set-Location) felt verbose at first. He mitigates this with aliases (ls, cd) but appreciates the clarity that the full cmdlet names provide, especially for newcomers reading a script.

Hybrid environments with WSL

In mixed Windows‑Linux labs, the Windows Subsystem for Linux (WSL) lets Korbin launch a single PowerShell session that can interact with both Windows APIs and Linux file paths. This eliminates the need to switch shells or maintain duplicate scripts. Features such as SecureString for credential handling and robust error‑handling constructs (try / catch / finally) are not natively available in Bash, making PowerShell a compelling choice for longer, more intricate automation tasks.

The author stresses that while Bash still wins on sheer portability, PowerShell’s cross‑platform builds behave identically on each OS, giving him confidence to use it for the majority of his own scripts—whether they run on a home lab VM, a VPS, or a corporate Windows server.

It’s time to recalibrate PowerShell’s reputation

Korbin concludes that PowerShell will not replace Bash, but it has earned a permanent spot in the toolkit of anyone doing serious scripting, especially in Windows‑centric or hybrid environments. The object pipeline alone justifies the learning curve, and the criticisms that once plagued PowerShell—Windows‑only availability and clunky syntax—are largely obsolete. Most Linux users, if they take a moment to explore the modern PowerShell, will be surprised by its maturity and utility.