As great and streamlined as the Windows desktop experience is, one area where it’s at best disappointing and at worst rage-inducing is when it comes to its command line interface (CLI) offerings. In Windows 9x/ME this could be excused by the fact that it was essentially just a dressed-up MS-DOS CLI experience, but on Windows NT-based OSes no such excuse exists.Yet even after Microsoft finally acknowledged the shortcomings of the cmd.exe shell by 2006, they then proceeded to go their own way with PowerShell, industry standards be damned. Especially for those of us who have no beef with the UNIX/BSD/Linux CLI experience and the joys of shell scripting, this insistence was disappointing. Simultaneously, everyone from OS X/MacOS to Haiku were happily offering a familiar CLI environment alongside POSIX compatibility.Although Windows NT OSes were POSIX compliant, they never offered a suitable shell along with it, nor any of the other things you’d expect in a modern-day BSD, Haiku or Linux CLI environment. In a recent article by my esteemed colleague Al Williams, these sore points were somewhat addressed as far as basic CLI tools go, but the issue goes obviously much deeper than just the basic userland tools. Which is where MSYS2 comes into the picture.Defining The ProblemWhen one says that they’d like a ‘Linux shell on Windows’, it can be hard to pin down exactly what this means. As Al noted in his article on CoreUtils last week, there are solutions like Cygwin that add a translation layer between Windows and Linux-ish code and offer a basic shell experience, but what if you really want to have a full Linux-like shell experience including support for common POSIX tools and libraries, as well as typical tooling like make and gcc?Microsoft’s CoreUtils package gets you a GNU userland-like experience, but that’s arguably a small part of the whole issue. The reason why over the years I drifted away from Linux tools ported to Windows – as well as bailed on WSL, WSL2, Cygwin and full-fat VMs – is due the amount of friction these added when all that I wanted was to use a Bash-like shell for day-to-day tasks and general software development. For all intents and purposes I wanted to pretend that I was just on a modern Linux distro like Arch without having to fire up some special application with significant overhead or waddle over to one of my systems that have Linux installed.This means a GNU-style userland, basic POSIX compatibility, being able to run shell scripts, having access to a package manager like on BSDs/Linuxes/Haiku/etc., ideally all in a way where it blends quite seamlessly into the overall Windows GUI experience. Essentially the laziest and most off-the-shelf experience possible, if you want.This is where a full-fat VM is obviously too heavy and restricted, while WSL(2) also carries too many of the VM-related flaws with it, as it’s too much trying to be Linux instead of integrating with the Windows experience. The ideal solution here would probably feel more like the standard terminal on Haiku.The MSYS2 SolutionWith MSYS2 you can use the same pacman package manager you’d use on Arch/Manjaro to fetch packages. You’re also using a regular Bash shell and the only major hurdles you’re likely to run into concern limitations with low-level tools like Valgrind and some Windows-related quirks that the MSYS2 developers can’t do too much about because Microsoft. Internally it’s still based on Cygwin, so you can count on a similar level of compatibility, but without fuss.For day-to-day use it’s a very familiar Linux-like experience for especially software-development purposes and common shell-based shenanigans like automation tasks and running a range of tools such as ffmpeg and yt-dlp, both of which are of course readily available from the package repository. In this sense MSYS2 adds a terminal and CLI environment that blurs the lines between BSD/Haiku/Linux and Windows, just the way us cross-platform developers like things, as this way you can use the same scripts and same know-how and muscle-memory across terminals and TTYs.Perhaps the only negative here is again due to MSYS2 being not fully integrated into Windows, resulting in e.g. binaries compiled within an MSYS2 environment relying on shared libraries that are not on the Windows system path. This can be worked around by copying all the DLLs into the binary folder, or doing system path things, but it’s one of the reasons why I do distribute binary builds for Windows of my OSS projects that are compiled using NMake and MSVC.The MSYS2 EnvironmentsWhen you first install MSYS2, the most important thing to learn are the distinctions between the various MSYS2 environments. This is the first thing you see after happily installing MSYS2, finding yourself staring at a list of various terminal options, as summarized below. Over the years a number of these environments have been retired, in particular the 32-bit environments, but also the MinGW64 environment that used to be the primary one until Windows 10 added the Universal C Runtime (UCRT).The MSYS2 environments page provides a lot more detail, but the brief summary is that you should just use the UCRT terminal. It builds upon the MSYS environment just like the other options, essentially setting up a number of defaults, with some of these listed in the above table. Although you can use the Clang environments, these aren’t nearly as mature or full-featured, so your mileage may vary there.Development FeaturesMy basic software development workflow involves Notepad++ to write code and a Makefile, and the use of an MSYS2 UCRT terminal to run make, along with gdb, grep and utilities such as ldd for happy-fun debugging purposes. When I do embedded development that targets e.g. STM32, I can fetch the entire GCC-based toolchain for ARM Cortex-M via pacman and use that in exactly the same way as I would in a Linux-based terminal or TTY.I have always found doing such development things the ‘Windows way’ to be rather tedious and cumbersome, having spent considerable time in the past using environments like Visual Studio and other IDEs such as Code::Blocks. While any approach can be made to work, just being able to use the same shell scripts, same gdb configurations, and the same Makefiles. across FreeBSD, Linux, Haiku, and Windows saves a lot of time and effort as you never have to duplicate effort.MSYS2 LimitationsAs alluded to earlier, MSYS2 doesn’t integrate perfectly in Windows as it is still just a third-party application. It also only covers userland, so kernel-level drivers and tools like Valgrind will require a full-blown Linux system. However, unless I’m doing some crazy involved profiling or debugging I’ll generally just use Dr. Memory on Windows, which works the same as Valgrind and also has packages for Linux and MacOS.Whether it’s a limitation or not I’m not entirely sure, but stdout in MSYS2 Bash also sometimes does seem to have trouble outputting where Bash or similar on BSD/Haiku/Linux does not, which is an issue that I still need to diagnose in more depth one day to file a ticket for. That said, having created issue tickets for the MSYS2 (packages) project in the past has at least made it clear that its developers are quite responsive and fairly tame.These minor niggles aside, I’m quite grateful to the MSYS2 project for allowing me to have both the solid Windows GUI experience and also have my heavily Arch-inspired CLI cake with pacman icing.