alt Hacker NewsCoreutils for Windows
Comments
> Several commands share names with built-ins in CMD and PowerShell. Whether the Coreutils version runs depends on the shell, the PATH order, and (for PowerShell) the alias table.
Well this is not very satisfying, what about proving a way where it actually works without us having to guess where the failure root cause happens to be?
WSL1 is generally better for these usecases.
So dir is not shipped due to conflict with built-ins, echo and rmdir are shipped despite conflicts, and sort is deemed not to have a conflict? What is the logic?
I wonder if the motivation is to make Ai agents work better on Windows?
I would have liked to see head, tail, tr, uniq, and cut. I end up dragging over the old "gnuwin32" versions of those to a lot of Windows machines. Those are my go-to tools for quick-and-dirty log analysis.
I know I could use Powershell for those kinds of tasks, and I certainly do make a lot of use of Powershell, but the familiarity of those simple tools and the decades-old "muscle memory" of using them on various Unix, Linux, and Windows boxes makes them hard to ditch.
winget install -e --id frippery.busybox-w32
I feel like I'm seeing an error, or I just don't understand what they mean w/ "find" and "Integrated port of the original DOS command" and not listed as conflicting.
There's a "%SystemRoot%\System32\find.exe" on every Windows NT-derived OS. That's absolutely a conflict.
Also, the "find" command from "findutils" is in no way functionally similar to the "original DOS command" (which is for finding text in files).
Aside: Eschew "find.exe" on Windows for "findstr.exe". The latter is vastly more efficient. I discovered that by happenstance once and have trained my hands to type "findstr" when I mean "find" on Windows.
For the MS folk reading this: native zsh on Windows, please?
WSL2 is great, but native POSIX is even better. Of course it’s a big undertaking, but it makes Windows a first-class dev platform for those who need POSIX in production.
FINALLY. This is actually exciting to me... Mind you the linux ports (cygwin, msys2, git bash) are all great to have and I make sure one version or the other is always on my path but having MS maintain them (assuming they continue to do so) is great news
You can install gnu-compative shell commands when installing git for Windows. It even includes useful unix utilites like bash, so check it out if you're interested.
More project information: https://gitforwindows.org/
Official download: https://git-scm.com/install/windows
In the intentionally dropped section, it lists shed as "Not particularly useful on Windows." Does anyone know why? Is thre already a shred-like command in Windows?
Cool. I'm already using cygwin for a lot of these utilities. Would the Microsoft versions have any advantages?
What about "ln" (make symbolic links)?
https://www.gnu.org/software/coreutils/manual/html_node/ln-i...
There's also a windows port of busybox if you want something more stable. w64devkit uses it.
No thanks, I'd rather use linux.
Will we ever see a Windows-optimized version of unix utilities that avoids creating new processes? It seems like that's the step that's really slow, and if you could reuse a process to continue running more commands, that would speed things up a lot.
Nice. I appreciate the effort to make things less painful for powerusers. I had noticed some of these working already in PS.
If anyone from MS is reading this can we please also get an equivalents (or even alias) for the thing that shows IP address? The windows equivalent of "ip a" is some convoluted PS command that I can never remember
A fair question is why this fork of coreutils is required when the original Rust rewrite (https://github.com/uutils/coreutils/) supports Windows, in addition to Linux, macOS and wasm.
The reason seems to be a few windows specific fixes (https://github.com/uutils/coreutils/compare/main...microsoft...) which can probably be upstreamed into the main repo.
Microsoft provides an awesome problem-solving solution, and 0 of the 6 problems they listed in the 'Windows caveats' section are solved.
Linux: first they laugh at you, then it embraces, extends, and extuinguishes Windows.
Native Coreutils for Windows is genuinely some good news coming from Microsoft.
Is this only on windows 11 or does it support 10 as well? (i cant access the site rn because of wifi)
Yeah, we don't hate this uutils (NOT coreutils) project enough.
FWIW, most of the powershell builtins are aliases for weaker methods like grep / select-string or cat for Get-Content. So you could likely install this without breaking anything.
I didn’t see less or a decent pager. MS needs their analytics on WSL and implement the top 50 commands on powershell
Powershell is very good, but lacks brevity and convenience of coreutils so this should be a big win.
Isn't this just a restricted uutils fork? With most functionality culled for no good reason? "uname isn't useful on Windows" how? OSName/ Build numbers / systeminfo all exist?
Would it make sense to add a prefix to all commands to avoid conflicts with built-in commands? Like how, on macOS and FreeBSD, installing GNU Coreutils adds a `g` prefix, Microsoft could add an `m` prefix to these commands.
Is 'dir' a Linux command?
I just have msys on my PATH.
That's actually a good idea. Now, I am a Linux person, but I have windows on a secondary machine. Compiling on Linux is trivial.
On Windows it is possible of course, WSL, msys, what not, but it is cumbersome. And I hate the default compiler on windows. So if coreutils on windows helps simplify all the base toolchain, I am all in favour of it. Windows really needs to make compiling stuff a LOT easier by default. I don't want to download some x GB of stuff I don't really need.
Busybox for Windows is the best implementation of coreutils for it, far and away. The maintainer is also very knowledgeable and responsive and actually merges community PRs which is incredible. Microsoft isn't going to do that, so why bother? Microsoft's solution will be a hot buggy mess that needs its own workaround and quirks day 1.
[dead]
uutils coreutils was/is already available and more complete than this
Was not expecting EEE for Coreutils but I suppose it’s the natural consequence of the MIT license used for uutils so not totally unexpected.
It’s annoying enough to support the differences between BSD and Linux, and now Linux has GNU and uutils, and now we’re gonna need Windows variant of uutils…ugh.
Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX.
In powershell everything is much better than cmd, but it's just not enough.
WSL is generally great, but there are annoying downsides. I often get "catastrophic" crashes and the zone identifier files drive me nuts. Plus it takes so much longer to start VSCode when connecting with WSL, and now you've got two file systems. WSL1 was in many ways better than WSL2 for these reasons.