GNU Coreutils Now Run Natively on Windows

You type ls on a Windows terminal. Nothing. You try cat. Nothing. uptime. Nothing. You sit there for a second wondering if your muscle memory has just completely betrayed you, and then you remember — oh right, wrong OS. Again.

If that loop is your whole life, Microsoft just patched it.

The company has officially ported GNU Coreutils to Windows as native binaries — meaning the same foundational commands you use on Linux or macOS now work directly on Windows, no emulation layer, no WSL, no Git Bash workaround holding it together with tape. Gary Sims over at Gary Explains just walked through the whole thing, and I've been sitting with it since because honestly? My reaction is more complicated than "cool, solved." Let me explain why.

Okay but first — can we just take a second to appreciate the historical comedy here? In 2001, then-Microsoft CEO Steve Ballmer called Linux "a cancer that attaches itself in an intellectual property sense to everything it touches." That's a real quote, from a real press interview, said by the actual CEO of Microsoft. And now, in 2024, Microsoft is shipping GNU tools — the same open-source utilities that power Linux — directly through its official package manager. The company didn't just make peace with open source; it became a distributor of it. Whether you find that inspiring or deeply ironic probably says something about how long you've been watching this particular drama unfold. 🍿

This isn't the first time Microsoft moved in this direction. WSL — the Windows Subsystem for Linux — was announced at Build 2016 and gave developers a way to run a Linux environment inside Windows. That was a big deal! But WSL is still its own sandboxed thing. You're running a Linux kernel alongside Windows, not instead of booting into a separate machine, which is genuinely useful, but it still feels like a guest room rather than a first-class space. Native Coreutils is different in kind, even if it's smaller in scope. These aren't Linux commands being tunneled through a compatibility layer — they're recompiled from the same open-source code and running directly as Windows executables.

So what actually gets installed? According to Gary's walkthrough, you're looking at around 78 commands — the exact count may shift depending on the release version, so worth checking the GitHub repo for your specific build. The install itself is either a winget one-liner or a manual download from GitHub. That's it. Once it's there, you get ls, cat, uptime, head, tail, sort, tr, fold, wc, pwd, and a whole lot more, all working the way you'd expect them to work if you learned them on Linux first.

And this is the part that actually matters most, especially if you're newer to all this — these tools aren't just individual commands. They're designed to talk to each other. Think of them like LEGO bricks: each one does one small thing, but you can connect them in a line and suddenly they're doing something you couldn't do with any single piece alone. Gary demonstrated this with a chain of 13 commands piped together — generate numbers, randomize them, sort them, strip duplicates, add line numbers, replace spaces with underscores, wrap the text, reverse it, count the lines, print a summary. It's completely pointless as a task, but the point isn't the task. It's that you just watched 13 simple tools combine into one coherent operation in a single line. That's the whole Unix philosophy in miniature, and if you've never seen it click before, watching it work on Windows for the first time is kind of a "wait, that's it?" moment — in the good way.

Now. The friction. Because there's friction.

Command Prompt is mostly fine. Gary ran ls, uptime, ls -1 | wc -l — all worked cleanly. The wrinkle is that some Coreutils commands share names with commands already built into Windows. mkdir is the example Gary flagged: it exists in both places, and Windows grabs its own version first. If you try mkdir --version expecting the Coreutils response, you don't get an error — you get a folder literally named --version sitting on your filesystem. You have to stop and rmdir -- --version to clean it up.

I love this bug. Not because it's good, but because it is so perfectly illustrative of what happens when two different tool traditions collide. One world where --version is a universal flag that every well-behaved program should honor; another world where the shell just… doesn't have that concept. It's a little namespace collision that tells you everything about why this transition, however welcome, isn't frictionless.

PowerShell is where it gets more interesting. PowerShell has its own versions of commands like cat and ls — they're aliases for PowerShell's native cmdlets — and those take precedence. Type cat --version in PowerShell before loading Coreutils properly and it stares at you blankly, like you just asked it a question in the wrong language. Gary's fix is a shell script that sets up aliases pointing PowerShell at the Coreutils versions instead. Run it with the dot-source command (. ./coreutils.ps1 if you want the syntax), and now ls --version correctly identifies itself as the Coreutils build. Gary is sharing that script on his GitHub, which is a nice move — it's exactly the kind of setup-once, forget-about-it glue that turns a "technically works" situation into something you'd actually use day-to-day.

As Gary puts it: "You can actually override the built-in commands inside of PowerShell by using those coreutils ones, which is really really useful." That's the undersell of the year, honestly. For anyone bouncing between a Windows dev machine and a Linux server, or grinding through a bootcamp that assumes you know your way around a Bash terminal, having your muscle memory actually work on Windows is not a small thing.

One note: Gary mentions the binaries land in C:\Program Files\coreutils\bin when installed via winget, but default install paths can vary — especially between winget and a manual GitHub install. Worth double-checking where your system actually dropped them before you go editing PATH variables.

Here's the thing I keep coming back to: who is this most useful for right now?

Not the person who's been on Linux for a decade — they probably have WSL configured exactly how they want it and aren't looking to change their workflow. Not the person who's 100% Windows-native and never touches a terminal — they don't have the muscle memory to miss in the first place.

It's most useful for the person in the middle. First dev job, and the production server runs Linux but your work laptop runs Windows. Self-taught, learned everything on Ubuntu tutorials but your gaming rig is Windows. Running a homelab, trying to make sense of why the exact same command behaves differently depending on which machine you typed it on. That gap — between "I know what I'm supposed to type" and "the OS is actually going to do what I expect" — is real, and it's specifically the thing Microsoft just shrunk.

"Completely pointless, yes, absolutely," Gary says of his 13-command demo chain. "But the point is it just shows you the power of using the core utils here in the PowerShell."

Yeah. That's exactly right. And "the power" here isn't a feature list — it's fluency. It's the difference between a Windows terminal that fights your instincts and one that finally speaks the language you already know.

You opened a terminal. You typed ls. It worked.

That's not nothing.

By Zara Chen, Tech & Politics Correspondent