Why I Switched from Bash to PowerShell... Or Did I?

Welcome to the Issue #004 of the /dev/stdout newsletter. I briefly explain why I ditched Bash for PowerShell in this short summer issue.

Table of Contents

• But Bash on Windows is doable, right?

• PowerShell to the Rescue

• Conclusion

A while back I got involved in a project where I was tasked to improve Developer Experience throughout the company’s development teams. Teams there use mostly either Windows or MacOS as their daily drivers. My work involves creating automation to help development teams focus on their tasks instead of dealing with infrastructure and the development environment. I will mainly improve the local development experience, so the automation needs to run on people’s local machines.

There is something fresh in those requirements for me, as I have been working on the Unix side for quite some time now, solely on Linux for the last few years.

But Bash on Windows is doable, right?

I thought I could easily get away with using either Bash on Windows or native Bash on Windows Subsystem and the Linux running there. MacOS has its own Bash issues, but I was not too worried about those in this specific case.

How wrong I was! While Bash is cross-platform, it requires some extra effort to make it work in an environment where the same Bash script is, used in Windows by one person, while another runs it in MacOS, and a third uses it in Linux.

Why? You might ask. Well because of the line-endings. When a Bash file is saved in Windows it cannot be run on Linux or vice-versa.

As always, there are ways to solve this, but nothing robust enough for our use case. We could not justify adding extra .gitattributes, or using tools like unix2dos only to solve this particular issue. Using these would have contributed to unnecessary complexity.

PowerShell to the Rescue

After a brief discussion with the team, we concluded that using PowerShell might make sense here, especially as it was used already in the company.

PowerShell is an open-source, multi-platform project that supports MacOS, Windows, and Linux. So based on those characteristics, it seemed to fit perfectly to our problem.

I had no prior real experience in it. After having spent a big part of my career out of Windows systems, I admit, I was a bit skeptical.

After having dabbled with it for a day or two I started to like it. The skepticism slowly started to fade away after I got used to this somewhat distinct Verb-Noun (like Get-Content ) based on the syntax of PS.

Things I like in PowerShell:

• Everything is an object, unlike Bash, where everything is a string.

• A wide array of language constructs that are familiar to many from other programming languages, such as switch and enum.

• switch supports destructuring and pattern matching. This is one of my favorite feats in any language that supports this.

• It comes with a native testing framework, called Pester.

• It’s got a solid ecosystem of packages

• It’s cross-platform

• It’s nowadays Open Source

Conclusion

A jump to PowerShell was a real eye-opener for me, and it’s likely I will find other use cases for it outside of this project. For me due to the many upsides of PowerShell, using it might not always require cross-platform situations.

Will I start using it often instead of Bash? I do not think so! The upsides of using Bash or even sh are huge when doing automation on Linux or Unix anyway. Not the least because they’re natively installed and work (more or less) the same way everywhere.

Let me know how you resolved the cross-platform Bash problem. Or any similar situation!

Would you like to discuss how to improve the Developer Experience in your organization?

Thanks for reading and have a great late summer!

Best,
Pyry

P.S. Writing this issue was powered by listening to:

_{*You might wonder what the song recommendation has to do with anything. Well, as I often listen to music while I write, be it this newsletter, documentation, or code, I wanted to share some of that with you too. I hope you like them!}