> 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?
I was going to comment that any sort of script that you are using in multiple environments probably should have all of the paths completely written out. I usually try to do this myself as I have gotten burned by binaries from unexpected paths on new systems a number of times.
But then I realized that the point of this project is to make it easy to write scripts that can be used on multiple OSs... and that is going to make fully-qualified paths possibly a nightmare. Anyone know if these get put at `/bin/`?
A big part of the point is so you can use scripts made for other platforms on windows natively, which you lose when you have to alter them to pass absolute paths
Busybox helps you avoid this nicely on Windows. When you run one of one of its shells, it uses all it's own builtins in preference to anything external.
Get the 64-bit version: "there's some advantage in using the 64-bit executable busybox64.exe. In particular, it can be quite a bit faster."
Busybox is nice, but it's kind of like the Blender default cube to me: my only memories of it are removing it on sight to replace with something better.
It actually failed even before that. The project states "The goal is to make moving between Linux, macOS, WSL, containers, and Windows frictionless: the same commands, flags, and pipelines work the same way, so *existing scripts carry over without translation.*"
... but they failed to provide a port of Bash - so how exactly do they expect someone to run a bash script in Windows "without translation"? If the answer is WSL, then there's no need to port the coreutils over because WSL distros already include them. If the answer is to port the scripts over to PowerShell, then you wouldn't want to call Windows coreutils in your PowerShell scripts and run into unexpected behaviour (and also lose out on the object manipulation advantages of PowerShell).
And finally, they failed to port over commands that would actually be useful - like dd, for writing ISOs to a flash drive or backing up drives. chroot could've taken advantage of Windows' new sandbox feature to switch to a virtual C: drive. chown could've been an easier alternative to takeown/icacls. chmod could be used to remove the annoying network file blocks and also change file attributes and so on.
This whole project seems like a half-assed attempt at nothing.
Maybe someone out there mixmashes PowerShell, bash, sh and cmd scripts from different platforms in one session - but usually it's one, quite straightforward 'flow' which requires a quite specific environment.
The best part is the reason it conflicts with a lot of PowerShell is PowerShell shimmed Linux commands over to their Windows equivalents for years even though the flags were different.
So ls in many systems will match the behavior of dir, and only accept the flags for dir. But if you use a system with the newer coreutils release here, ls will expect ls flags!
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.
"UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.
"UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII. It has never gained popularity on the web, where it is declared by under 0.004% of public web pages (and even then, the web pages are most likely also using UTF-8). UTF-8, by comparison, gained dominance years ago and accounted for 99% of all web pages by 2025."
NT shipped with USC-2 as UTF-8 (and -16) did not yet exist. USC-2 naturally translated to UTF-16, hence the choice. NT/Win32 is also designed for fixed-with code units, something UTF-8 doesn't support.
You can use UTF-8 on a per-application basis, within limits.
Additional Detail: it is specifically utf-16 little endian when a byte order mark is not used, which is the opposite of the recommended choice of big endian in the RFC.
Worse are the byte order marks required to support both endians that end up in files.
UTF-16 is also used by C#, Java, and JavaScript. Since JavaScript is so widely adopted, I wouldn't call it a rare bird. Not necessarily used when reading or writing files, but it's what's used internally for the strings. As a result, your strings use UTF-16 surrogate pairs to represent characters outside of the basic multilingual plane (such as Emoji).
Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.
> ... Or better yet, just switch everything to full POSIX.
Interix[0] did a pretty good job of this, but MSFT killed it. I was compiling GNU tools w/ GCC and running bash under Interix back in in 2000 under Windows 2000. It was grand.
> Or better yet, just switch everything to full POSIX.
Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level). Windows technically provides some of them (or semantic equivalents) so you could make something work, but in order to do a full port you'd need to strip out too many concepts for it to be worthwhile. For instance the idea that "everything is a file" or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
Yesterday for me was the last time. Visual studio 2026 default to crlf I think maybe and I have autoctlf in git turned off. I should probably turn that back on.
powershell is good. its much better than unix's everything piped is Text idea. godawfull that. outputs being objects is a really solid take.
WSL is trash.
besides that, lf vs. crlf is silly as you mention but crlf is more logical considering what its implementing. that being said the notion of these control chars is already based on outdated and limited ideas.
if you want a consistent system to do things with dont pick a system which tries to be two systems.
Linux has wine. Windows has WSL.
I'd recommend BSD. any flavor will do.
might take some adjustments but you will have a more 'rational' system if that is what you desire.
Being able to go someoutput | Format-Table | Select ColumnName,ColumnName,CloumnName is great. Beats memorizing the output format of any specific command and trying to wrangle it with awk.
I'm a big Linux advocate with limited experience on modern versions of Windows, but PowerShell objects are great. So is the Unix way of doing text. I think the strengths of each approach are in different use cases. Unix style is better for interactive usage because it's fast, I can type df -h | grep /home very quickly. Object output is better for scripts that can, thanks to objects, store and operate on sensible data while Bash scripts do a lot of ad-hoc data extraction/reformatting with string expansion, awk and whatever else to get data to the next step in the script.
I have absolutely zero sympathy for any tool that is incapable of handling \r\n and only works with \n. Literally absolutely no sympathy.
All software accumulates warts over time. Linux is overflowing with horrible warts and tech debt. As is any software that has successfully served customers for decades.
But multiple line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.
> But line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.
The Linux ecosystem handles it fine (by using a single standard). Windows doesn't. That's its problem.
No, they need to ditch drive letters first. The NT kernel and NTFS don't even require them (I used to mount disks without drive letters back in the NT 4 era). They just don't care enough to get rid of this annoyance.
users , especially non-technical, find it highly useful in my experience. Is it a net positive to get rid of them, or will it largely only make developers happier ?
The intent was simply to give people coming from macOS and Linux more of the CLI tools they're familiar with. In other words, agents weren't the focus at all.
But if it ends up helping them, that's a good added benefit of course.
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.
nope. With ClaudeCode you can create skills ( basically markdown instructions) to teach your agents what command to use. You can also update CLAUDE.md to inject custom instructions that are feeded anything ClaudeCode is started.
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?
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.
They've already made a few attempts over the years (Windows Subsystem for UNIX comes to mind), neither really caught on, except WSL.
I also don't quite get why one would want such a setup - why not just use MSYS2 or WSL? As it is, it's just a mishmash of CMD builtins, Windows utils, Powershell, and these Coreutils. Will one have to use CMD-style (%var%) variables or will it be the POSIX way ($var)? Also just keeping in mind when to use /s or -s style switches, which version gets invoked depending on the PATH, PS aliases, etc. is just a lot of mental overhead for seemingly little advantage over WSL.
I apologize for asking, but did you also understood the "Shell conflicts" section as being the complete list of utilities? The project ships the majority of core utilities (~75%).
As hex4def6 said, the idea was that DOS command conflicts are not a good idea, while overriding PowerShell builtins in interactive sessions (PSReadLine) is acceptable, if not a good idea. We open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics.
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.
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.
I use those commands also to filter output and fee ai agents with that. Tail and Head are my favourites to avoid wasting tokens. Wayy too many fancy build logs messages.
Windows has lacked decent ports of recent GNU tools for a while. I still use some very old ones. It would be great if MS worked on the other tool groups like textutils.
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.
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.
We actually open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics. The installer allows you to pick what variant to use by default if the invocation is ambiguous.
I'm working with mostly "cattle"-type boxes with only the stock OS components installed so I "live off the land". On boxes that I treat as "pets" I do load other tools. A Win32 port of GNU grep has done well enough for me that I've never thought to look at ripgrep.
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.
Cygwin executables need cygwin1.dll to run while MSYS-based distributions are using Windows APIs directly. One major difference is around process management: in Cygwin fork() is implemented* while MSYS2 packages will need to use whatever the NT kernel provides (i.e. also need to modify the source to build for this target): https://stackoverflow.com/questions/985281/what-is-the-close...
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?
Shred isn't very useful on SSDs in general. Because of TRIM, deleting a file instantly makes the sectors read back as 00 bytes. (Yes the data is technically still on the flash chips scattered across memory blocks without any mapping telling you where each piece of the data is, but is not readable through normal drive commands)
It depends on the firmware running on the SSD, so theoretically it’s possible but practically it’s not. Instead, SSDs use a special command to zero all cells on the chip at once, so it’s all or nothing. You can’t target specific files.
To clarify: the host can issue a command to the SSD to securely wipe the whole drive including spare area that is not directly accessible to the host. The SSD controller in the drive issues erase commands to the NAND to erase individual erase blocks, with typical sizes on the order of 16MB.
The SSD controller does not usually keep a history of where older versions of a block of data were stored, so it's not practical to erase an individual file and catch any partial older versions that may not yet have been garbage collected.
The filesystem may choose to store new data at different logical block addresses than older versions. The SSD will definitely choose to store those newly written blocks at different physical addresses, both for the sake of wear leveling and for performance, because a read-erase-rearite cycle on an entire NAND flash erase block (several MB at minimum) is a very slow operation.
No. Shred will "work" - as in, compile, run, and have the expected logical effects of ultimately removing the file from the directory index - on any filesystem backed by any block device. The problem is that overwriting any part of a file is not guaranteed to actually erase the overwritten data. Actually, it never has been; shred is kind of a hack that assumes an overwriting file system driver and a block device dumb enough to not remap sectors writing to media that's intrinsically erasable. e.g. try running shred on a mounted CD-R and see how far that gets you.
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
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
You could also make your own alias if you specifically want to type "ip a" just add a powershell function to your $PROFILE. function ip { param($argument)...." etc. have it call Get-NetIPAddress, else fallback to ipconfig.
Christ. I'm guessing it's to be BSD so they can pull it back and keep it proprietary at any time also. Never trust Microsoft to act in good faith. We USE THE GPL for a reason.
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?
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.
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.
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.
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.
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.
> 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?
How do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?
Fully-qualify the path to the target program, and it should be no concern.
What a great developer experience out of the box!
I was going to comment that any sort of script that you are using in multiple environments probably should have all of the paths completely written out. I usually try to do this myself as I have gotten burned by binaries from unexpected paths on new systems a number of times.
But then I realized that the point of this project is to make it easy to write scripts that can be used on multiple OSs... and that is going to make fully-qualified paths possibly a nightmare. Anyone know if these get put at `/bin/`?
On nixos they're not, there's a single executable in /bin -- /bin/sh, and a single executable in /usr/bin -- /usr/bin/env
A big part of the point is so you can use scripts made for other platforms on windows natively, which you lose when you have to alter them to pass absolute paths
Busybox helps you avoid this nicely on Windows. When you run one of one of its shells, it uses all it's own builtins in preference to anything external.
Get the 64-bit version: "there's some advantage in using the 64-bit executable busybox64.exe. In particular, it can be quite a bit faster."
https://frippery.org/busybox/index.html
Busybox is nice, but it's kind of like the Blender default cube to me: my only memories of it are removing it on sight to replace with something better.
It actually failed even before that. The project states "The goal is to make moving between Linux, macOS, WSL, containers, and Windows frictionless: the same commands, flags, and pipelines work the same way, so *existing scripts carry over without translation.*"
... but they failed to provide a port of Bash - so how exactly do they expect someone to run a bash script in Windows "without translation"? If the answer is WSL, then there's no need to port the coreutils over because WSL distros already include them. If the answer is to port the scripts over to PowerShell, then you wouldn't want to call Windows coreutils in your PowerShell scripts and run into unexpected behaviour (and also lose out on the object manipulation advantages of PowerShell).
And finally, they failed to port over commands that would actually be useful - like dd, for writing ISOs to a flash drive or backing up drives. chroot could've taken advantage of Windows' new sandbox feature to switch to a virtual C: drive. chown could've been an easier alternative to takeown/icacls. chmod could be used to remove the annoying network file blocks and also change file attributes and so on.
This whole project seems like a half-assed attempt at nothing.
Bash itself is an odd duck in scripting, with some dark historical crevices: http://tiswww.case.edu/~chet/bash/POSIX
A better option is a pure POSIX shell, the best-known of which in Linux is dash, but there is an existing Ada port to Windows here:
https://github.com/AdaCore/gsh
If non-POSIX features are required, the Android decision for mksh might suggest oksh for Windows.
Don't do the absolute paths. Do the environment.
Maybe someone out there mixmashes PowerShell, bash, sh and cmd scripts from different platforms in one session - but usually it's one, quite straightforward 'flow' which requires a quite specific environment.
Maybe it’s for the llm tool use PATH?
That was the most plausible reason to even mention it, that I could think of.
The best part is the reason it conflicts with a lot of PowerShell is PowerShell shimmed Linux commands over to their Windows equivalents for years even though the flags were different.
So ls in many systems will match the behavior of dir, and only accept the flags for dir. But if you use a system with the newer coreutils release here, ls will expect ls flags!
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.
Windows is also a rare bird in UTF-16.
"UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.
"UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII. It has never gained popularity on the web, where it is declared by under 0.004% of public web pages (and even then, the web pages are most likely also using UTF-8). UTF-8, by comparison, gained dominance years ago and accounted for 99% of all web pages by 2025."
https://en.wikipedia.org/wiki/UTF-16
NT shipped with USC-2 as UTF-8 (and -16) did not yet exist. USC-2 naturally translated to UTF-16, hence the choice. NT/Win32 is also designed for fixed-with code units, something UTF-8 doesn't support.
You can use UTF-8 on a per-application basis, within limits.
https://learn.microsoft.com/en-us/windows/apps/design/global...
Conversely, UEFI is UTF-16 only, thanks to Windows.
UTF-8 only would be an ABI breaking change, so that's not going to happen. We don't want the NT kernel to end up like Linux, after all :-)
> UTF-8 only would be an ABI breaking change, so that's not going to happen. We don't want the NT kernel to end up like Linux, after all :-)
I think you're making a joke, but it still doesn't make sense. Linux does avoid breaking changes to its userspace ABI
Additional Detail: it is specifically utf-16 little endian when a byte order mark is not used, which is the opposite of the recommended choice of big endian in the RFC.
Worse are the byte order marks required to support both endians that end up in files.
> Windows is also a rare bird in UTF-16.
Web browsers use UTF-16 internally. So Windows isn't even largest "platform" that uses UTF-16.
UTF-16 is also used by C#, Java, and JavaScript. Since JavaScript is so widely adopted, I wouldn't call it a rare bird. Not necessarily used when reading or writing files, but it's what's used internally for the strings. As a result, your strings use UTF-16 surrogate pairs to represent characters outside of the basic multilingual plane (such as Emoji).
No worries, eventually Xenix will make a comeback.
You cannot ditch CRLF, Microsoft isn't Apple.
Windows accepts backslashes and forward slashes, only old applications that manually search for one of them get it wrong.
Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.
At which layer? dir /w, for example, is never going to list the contents of \w.
Use powershell.
Get-ChildItem /w
Don't think this will ever happen, especially since this is Microsoft you are talking about [0]
[0] https://www.youtube.com/watch?v=bC6tngl0PTI
> ... Or better yet, just switch everything to full POSIX.
Interix[0] did a pretty good job of this, but MSFT killed it. I was compiling GNU tools w/ GCC and running bash under Interix back in in 2000 under Windows 2000. It was grand.
[0] https://en.wikipedia.org/wiki/Interix
I ported a million-line, OpenGL/Motif application using Interix (before it was acquired). Indeed, it was grand.
> Or better yet, just switch everything to full POSIX.
Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level). Windows technically provides some of them (or semantic equivalents) so you could make something work, but in order to do a full port you'd need to strip out too many concepts for it to be worthwhile. For instance the idea that "everything is a file" or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
On Windows, I've mostly avoided CRLF by configuring text editors and git to use LF, and writing text files in binary mode.
The only places that still forced CRLF were batch files and clipboard.
> I've mostly avoided CRLF by configuring text editors and git to use LF,
That has been my experience as well. I can't remember the last time I had an issue related to CRLF.
Yesterday for me was the last time. Visual studio 2026 default to crlf I think maybe and I have autoctlf in git turned off. I should probably turn that back on.
They might as well create a new OS with a different name, because none of the existing applications will work, and no enterprise customer will use it.
honestly your point is a bit weird.
powershell is good. its much better than unix's everything piped is Text idea. godawfull that. outputs being objects is a really solid take.
WSL is trash.
besides that, lf vs. crlf is silly as you mention but crlf is more logical considering what its implementing. that being said the notion of these control chars is already based on outdated and limited ideas.
if you want a consistent system to do things with dont pick a system which tries to be two systems.
Linux has wine. Windows has WSL.
I'd recommend BSD. any flavor will do.
might take some adjustments but you will have a more 'rational' system if that is what you desire.
(otherwise, embrace the madness!)
> outputs being objects is a really solid take.
Glad I'm not alone here ha!
Being able to go someoutput | Format-Table | Select ColumnName,ColumnName,CloumnName is great. Beats memorizing the output format of any specific command and trying to wrangle it with awk.
I'm a big Linux advocate with limited experience on modern versions of Windows, but PowerShell objects are great. So is the Unix way of doing text. I think the strengths of each approach are in different use cases. Unix style is better for interactive usage because it's fast, I can type df -h | grep /home very quickly. Object output is better for scripts that can, thanks to objects, store and operate on sensible data while Bash scripts do a lot of ad-hoc data extraction/reformatting with string expansion, awk and whatever else to get data to the next step in the script.
You can skip the `| Select` btw.
Just do `someoutput | ft ColumnName,ColumnName,CloumnName`
the two filesystems can be a super power... i seamlessly use the same driver between wsl2 and my dual booted opensuse.
Yeah I don't mind/like the two file systems. Looks like MS is taking it further too they also announced WSL Containers & API.
I have absolutely zero sympathy for any tool that is incapable of handling \r\n and only works with \n. Literally absolutely no sympathy.
All software accumulates warts over time. Linux is overflowing with horrible warts and tech debt. As is any software that has successfully served customers for decades.
But multiple line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.
> But line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.
The Linux ecosystem handles it fine (by using a single standard). Windows doesn't. That's its problem.
Comments like this really make me wish HN allowed you to block users. Alas.
> The Windows ecosystem handles it fine (by using a single standard). Linux doesn't. That's its problem.
It's always funny to see how the fanbois treat their way as the one and only 'True Way'.
>Windows really needs to ditch CRLF...
Windows needs to ditch itself.
No, they need to ditch drive letters first. The NT kernel and NTFS don't even require them (I used to mount disks without drive letters back in the NT 4 era). They just don't care enough to get rid of this annoyance.
Nobody wants to use \??\GLOBALROOT\Device\HarddiskVolume3\ in their paths.
users , especially non-technical, find it highly useful in my experience. Is it a net positive to get rid of them, or will it largely only make developers happier ?
I wonder if the motivation is to make Ai agents work better on Windows?
The intent was simply to give people coming from macOS and Linux more of the CLI tools they're familiar with. In other words, agents weren't the focus at all. But if it ends up helping them, that's a good added benefit of course.
Could come pre-installed with cygwin instead.
Cygwin isn't native Windows. Cygwin does many unholy things to enable signals and fork syscall in binaries.
uutils enables fully Windows native commands in the subset of system calls and disk structure Windows supports.
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.
Or you can tell your agent about it in one line of AGENTS.md.
nope. With ClaudeCode you can create skills ( basically markdown instructions) to teach your agents what command to use. You can also update CLAUDE.md to inject custom instructions that are feeded anything ClaudeCode is started.
If that was sufficient wouldn't it just be easier to map to the Powershell commands directly?
Claude code (at least the cli) has this, their code leaked so you can see their extensive (1000+ LOC) PowerShell took script.
Tool* (no edit button?)
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?
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.
They've already made a few attempts over the years (Windows Subsystem for UNIX comes to mind), neither really caught on, except WSL.
I also don't quite get why one would want such a setup - why not just use MSYS2 or WSL? As it is, it's just a mishmash of CMD builtins, Windows utils, Powershell, and these Coreutils. Will one have to use CMD-style (%var%) variables or will it be the POSIX way ($var)? Also just keeping in mind when to use /s or -s style switches, which version gets invoked depending on the PATH, PS aliases, etc. is just a lot of mental overhead for seemingly little advantage over WSL.
I apologize for asking, but did you also understood the "Shell conflicts" section as being the complete list of utilities? The project ships the majority of core utilities (~75%).
This smells like someone promotion to get the stuff shown at BUILD, like the old sudo as runas replacement, which I don't care it exists.
"Yo make some UNIX stuff to show at BUILD as developer tools".
Users might as well just use msys2.
As hex4def6 said, the idea was that DOS command conflicts are not a good idea, while overriding PowerShell builtins in interactive sessions (PSReadLine) is acceptable, if not a good idea. We open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics.
AI said to do it.
I think if it conflicts with a CMD command it's not shipped, but if it conflicts with a powershell command it's ok.
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.
> 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...
I use those commands also to filter output and fee ai agents with that. Tail and Head are my favourites to avoid wasting tokens. Wayy too many fancy build logs messages.
Windows has lacked decent ports of recent GNU tools for a while. I still use some very old ones. It would be great if MS worked on the other tool groups like textutils.
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.
The NT kernel could never implement full POSIX semantics. It would have to be another UN*X clone to do so.
And that would suck.
Surely WSL1 proves that it mostly can
https://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."
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.
We actually open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics. The installer allows you to pick what variant to use by default if the invocation is ambiguous.
Don't use find, use Voidtools' Everything. It finds filenames instantly, by searching the NTFS structures.
This is one of the few features that Linux file systems do not have.
Why not use ripgrep?
I'm working with mostly "cattle"-type boxes with only the stock OS components installed so I "live off the land". On boxes that I treat as "pets" I do load other tools. A Win32 port of GNU grep has done well enough for me that I've never thought to look at ripgrep.
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
Or MSYS2, to go even further. https://www.msys2.org/
Always wondered if git bash was cygwin, I don't think it is, but it seems very similar.
Cygwin executables need cygwin1.dll to run while MSYS-based distributions are using Windows APIs directly. One major difference is around process management: in Cygwin fork() is implemented* while MSYS2 packages will need to use whatever the NT kernel provides (i.e. also need to modify the source to build for this target): https://stackoverflow.com/questions/985281/what-is-the-close...
Close, it's MinGW/msys - different pathname semantics and under-the-hood approaches.
What about "ln" (make symbolic links)?
https://www.gnu.org/software/coreutils/manual/html_node/ln-i...
https://uutils.github.io/coreutils/docs/utils/ln.html
Any command not listed under the "Shell conflicts" section is included. In my testing `ln` works great.
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?
One possible alternative is cipher.exe: https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
Shred isn't very useful on SSDs in general. Because of TRIM, deleting a file instantly makes the sectors read back as 00 bytes. (Yes the data is technically still on the flash chips scattered across memory blocks without any mapping telling you where each piece of the data is, but is not readable through normal drive commands)
From shred man:
The shred command relies on a crucial assumption: that the file system and hardware overwrite data in place.
...
many modern file system designs do not satisfy this assumption. Exceptions include:
...
Log-structured or journaled file systems, such as.
...
NTFS.
I think SSDs also randomize where data ends up? But I'm not sure if that's true for existing files too.
Yes. All of the assumptions made with shred and sdelete apply only for spinning HDDs. SSDs require different methods of wiping.
Is there no way to track down where the data actually lives?
It depends on the firmware running on the SSD, so theoretically it’s possible but practically it’s not. Instead, SSDs use a special command to zero all cells on the chip at once, so it’s all or nothing. You can’t target specific files.
To clarify: the host can issue a command to the SSD to securely wipe the whole drive including spare area that is not directly accessible to the host. The SSD controller in the drive issues erase commands to the NAND to erase individual erase blocks, with typical sizes on the order of 16MB.
The SSD controller does not usually keep a history of where older versions of a block of data were stored, so it's not practical to erase an individual file and catch any partial older versions that may not yet have been garbage collected.
The filesystem may choose to store new data at different logical block addresses than older versions. The SSD will definitely choose to store those newly written blocks at different physical addresses, both for the sake of wear leveling and for performance, because a read-erase-rearite cycle on an entire NAND flash erase block (several MB at minimum) is a very slow operation.
I assume it requires something exposed by the underlying filesystem.
No. Shred will "work" - as in, compile, run, and have the expected logical effects of ultimately removing the file from the directory index - on any filesystem backed by any block device. The problem is that overwriting any part of a file is not guaranteed to actually erase the overwritten data. Actually, it never has been; shred is kind of a hack that assumes an overwriting file system driver and a block device dumb enough to not remap sectors writing to media that's intrinsically erasable. e.g. try running shred on a mounted CD-R and see how far that gets you.
Cool. I'm already using cygwin for a lot of these utilities. Would the Microsoft versions have any advantages?
No .DLLs would be the primary reason.
There'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"?
This one might interest you, although it's quite old.
https://unxutils.sourceforge.net/
Busybox's shell is ash, but the above set includes an old zsh IIRC.
Note also that the Frippery Windows busybox is available as a 64-bit version, in case 2gb is not enough (easy with some big awk associative arrays).
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
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
in PowerShell there is a built-in alias.
> gip
You could also make your own alias if you specifically want to type "ip a" just add a powershell function to your $PROFILE. function ip { param($argument)...." etc. have it call Get-NetIPAddress, else fallback to ipconfig.
ipconfig works pretty well.
Linux: first they laugh at you, then it embraces, extends, and extuinguishes Windows.
Microsoft provides an awesome problem-solving solution, and 0 of the 6 problems they listed in the 'Windows caveats' section are solved.
Yeah, we don't hate this uutils (NOT coreutils) project enough.
they should give up on the backwards slash.
Is this only on windows 11 or does it support 10 as well? (i cant access the site rn because of wifi)
Windows 10 is end-of-life; so the question itself is odd. It may work on Windows 10, but they definitely don't support an EoL version of their OS.
It should work on Windows 10. If you're using PowerShell, you do need to have v7.4 or later installed, however.
Native Coreutils for Windows is genuinely some good news coming from Microsoft.
The command line team has been doing some solid work for a while. I recognize lhecker from the also great wt & edit projects.
If you told me during the Windows 7 era the Windows CLI would not only be getting nice but getting pretty comfortable I would never have believed it.
Yeah, the problem with Windows isn't the command line team, the problem is the marketing & sales div using windows to push every other MS service.
If they just kicked them out and left the Windows div alone it'd be a decent OS. All the bones are there.
Hopefully these do not require a PhD to be implemented.
With these AI agents using lot of linux commands, I think they have to do it.
It's not coreutils. It's a rust slop.
Christ. I'm guessing it's to be BSD so they can pull it back and keep it proprietary at any time also. Never trust Microsoft to act in good faith. We USE THE GPL for a reason.
Ubuntu also replaced GNU coreutils with uutils recently, its not just Microsoft.
The project will deny it, but this is clearly an attack against the GPL
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?
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.
It was really obvious.
Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.
Such a blatantly obvious attempt to damage GNU
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.
Apparently the creator of the fork is also a maintainer of some uutils repositories.
The original one is not virtue signaling enough
So “supports Windows” doesn’t mean supports Windows.
What does this do that Cygwin doesn't?
this conflicts with native shell utilities of the same name - take that, cygwin!
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?
It's a GNU Coreutils command.
https://www.gnu.org/software/coreutils/manual/html_node/dir-...
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.
I just have msys on my PATH.
uutils coreutils was/is already available and more complete than this
citation needed
100% vibe coded.
Ok
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.
Exactly. The best Linux distro is Windows.
The case for that statement (if there's a case at all) is wsl. This is outside wsl.