Yeah, we don't hate this uutils (NOT coreutils) project enough.
Coreutils for Windows
111–120 of 260 posts
Re: Coreutils for Windows
#112Is this only on windows 11 or does it support 10 as well? (i cant access the site rn because of wifi)
It should work on Windows 10. If you're using PowerShell, you do need to have v7.4 or later installed, however.
Re: Coreutils for Windows
#113I 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 Uni…
> I would have liked to see head, tail, tr, uniq, and cut. The project includes all of those. Or were you talking about the past?
I'm a gigantic idiot who can't read. I was reading the table shell conflicts as all the included commands, and not just as a subset of commands that had shell conflicts.
A gigantic idiot. Sorry.
Re: Coreutils for Windows
#114There's also a windows port of busybox if you want something more stable. w64devkit uses it. https://github.com/rmyorston/busybox-w32
Not similar at all - too heavy weight when you just want to use a small tool.
How the heck is a portable 637KB .exe that doesn't require any installation, extraction or admin rights to run, "too heavy weight"?
Re: Coreutils for Windows
#115I wonder if the motivation is to make Ai agents work better on Windows?
For sure. I wonder how long until the agents learn about this though. At least a year, right?
Agents / models don't need to "learn" about this.
When on Windows, the models default to bash / coreutils conventions until they realize it doesn't work / not available unless explicitly instructed otherwise.
Even on Mac, they tend to default to bash instead of running things in zsh.
Re: Coreutils for Windows
#116Will 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.
Re: Coreutils for Windows
#117Earlier quoted context omitted.
No idea, this is broken at start, I would expect at least a reasoning on how they expect to improve the mess going forward. Otherwise just don't do it, if it is going to be a mess to work with.
There's almost no point to this, especially since they're already shipping a (strictly) limited subset with the reasoning "not useful on Windows" despite Windows equivalent facilities _clearly_ existing. They should have at least considered a full native port.
[deleted]
Re: Coreutils for Windows
#118https://frippery.org/busybox/ winget install -e --id frippery.busybox-w32
From the site, "there's some advantage in using the 64-bit executable busybox64.exe. In particular, it can be quite a bit faster."
Re: Coreutils for Windows
#119So 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?
No idea, this is broken at start, I would expect at least a reasoning on how they expect to improve the mess going forward. Otherwise just don't do it, if it is going to be a mess to work with.
Users might as well just use msys2.
Re: Coreutils for Windows
#120Earlier quoted context omitted.
> I would have liked to see head, tail, tr, uniq, and cut. The project includes all of those. Or were you talking about the past?
I'm a gigantic idiot who can't read. I was reading the table shell conflicts as all the included commands, and not just as a subset of commands that had shell conflicts. A gigantic idiot. Sorry.
I read the readme that way too - a table with included utils with conflict status, and a list of intenationally excluded utils.
But the rest are in there:
https://github.com/microsoft/coreutils/blob/3fa7aaf832ffc81d...