As the Windows desktop experience continues to impress with its streamlined interface, the command line interface (CLI) offerings often leave much to be desired. While earlier versions like Windows 9x/ME could be forgiven for their reliance on a dressed-up MS-DOS CLI, the same cannot be said for Windows NT-based operating systems. Even after Microsoft recognized the limitations of the cmd.exe shell by 2006, their decision to pursue PowerShell, diverging from industry standards, has disappointed many users who appreciate the UNIX/BSD/Linux CLI experience and the benefits of shell scripting. Meanwhile, alternatives such as OS X/MacOS and Haiku have embraced a familiar CLI environment with POSIX compatibility.
Despite Windows NT OSes being POSIX compliant, they have historically lacked a suitable shell and the expected features found in modern BSD, Haiku, or Linux CLI environments. Recent discussions, including insights from my colleague Al Williams on basic CLI tools, have highlighted these shortcomings, but the underlying issues extend far beyond mere userland tools. This is where MSYS2 steps in to bridge the gap.
Defining The Problem
The desire for a ‘Linux shell on Windows’ can be somewhat nebulous. As noted in Al’s article on CoreUtils, solutions like Cygwin create a translation layer between Windows and Linux-like code, offering a basic shell experience. However, for those seeking a comprehensive Linux-like shell experience—complete with support for common POSIX tools, libraries, and essential tools like make and gcc—the options have been limited. Microsoft’s CoreUtils package provides a semblance of a GNU userland experience, but this is only a fraction of the broader issue.
Over time, I found myself moving away from Linux tools ported to Windows, as well as abandoning WSL, WSL2, Cygwin, and full virtual machines due to the friction they introduced. My goal was simple: to use a Bash-like shell for daily tasks and software development without the overhead of launching a specialized application or switching to a dedicated Linux system. This ideal setup would include a GNU-style userland, basic POSIX compatibility, the ability to run shell scripts, and access to a package manager akin to those found in BSDs, Linux, and Haiku—all while seamlessly integrating into the Windows GUI experience.
In this context, full virtual machines prove too cumbersome, and WSL(2) suffers from the same limitations inherent to VMs, striving to replicate Linux rather than harmonizing with the Windows experience. The most desirable solution would evoke the simplicity of the standard terminal found on Haiku.
The MSYS2 Solution
MSYS2 offers a compelling alternative, allowing users to leverage the pacman package manager, familiar to Arch and Manjaro users, to easily fetch packages. With a standard Bash shell at your disposal, the primary challenges encountered are typically related to low-level tools like Valgrind and certain Windows-specific quirks that are beyond the control of the MSYS2 developers. Built on Cygwin, MSYS2 maintains a level of compatibility while minimizing complexity.
For everyday use, MSYS2 provides a Linux-like experience tailored for software development and various shell-based tasks, including automation and utilizing tools such as ffmpeg and yt-dlp, both readily available in the package repository. This integration blurs the lines between BSD, Haiku, Linux, and Windows, allowing cross-platform developers to utilize the same scripts and skills across different environments.
However, one drawback is that binaries compiled within the MSYS2 environment may depend on shared libraries not included in the Windows system path. This can be addressed by copying the necessary DLLs into the binary folder or adjusting system paths, which is why I often distribute binary builds for my open-source projects compiled with NMake and MSVC.
The MSYS2 Environments
Upon installing MSYS2, users encounter a variety of terminal options, each serving distinct purposes. While many environments have been retired over the years—particularly the 32-bit options and the former MinGW64 environment—the recommendation is to utilize the UCRT terminal. This environment builds upon the MSYS framework, establishing a set of defaults that enhance usability. Although Clang environments are available, they may not offer the same level of maturity and features.
Development Features
My software development workflow typically involves using Notepad++ for coding, alongside a Makefile, and executing commands in the MSYS2 UCRT terminal with tools like make, gdb, and grep for debugging. When working on embedded development projects targeting platforms like STM32, I can easily install the entire GCC-based toolchain for ARM Cortex-M via pacman, mirroring the experience I would have in a Linux terminal.
Having previously navigated the complexities of Windows-centric development environments such as Visual Studio and Code::Blocks, I find that utilizing the same shell scripts, gdb configurations, and Makefiles across FreeBSD, Linux, Haiku, and Windows significantly streamlines my workflow, eliminating redundant efforts.
MSYS2 Limitations
Despite its advantages, MSYS2 does not achieve perfect integration within Windows, remaining a third-party application. It primarily addresses userland needs, meaning kernel-level drivers and tools like Valgrind necessitate a full Linux system. For most profiling or debugging tasks, I prefer using Dr. Memory on Windows, which functions similarly to Valgrind and is also available for Linux and MacOS.
While it may not be a strict limitation, I have noticed that stdout in MSYS2 Bash occasionally struggles with output in ways that its counterparts on BSD, Haiku, or Linux do not. This is an issue I plan to investigate further and report to the developers, who have proven to be responsive and approachable in the past.
In light of these minor challenges, I remain appreciative of the MSYS2 project for enabling me to enjoy both the robust Windows GUI experience and a CLI environment reminiscent of Arch, complete with pacman for package management.
