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.
Windows NT shipped with three personalities, OS/2, POSIX and Win32.
OS/2 was more of a compatibility thing than anything else, given the OS/2 history between IBM and Microsoft.
POSIX subsystem was half backed implementation, only enough to check some boxes in US government contracts, naturally it never took off. In fact, many people including myself, only never considered GNU/Linux, if Windows NT POSIX support was at the same level as any other UNIX, like it happens on mainframe and micros OS environments, e.g. PASE on z/OS.
Then as Windows actually started to take over UNIX workstations, with Win32 as main subsystem, there was MKS Toolkit as commercial product, Microsoft felt the complaints about the POSIX subsystem, then we had Interix acquisition, which evolved into Windows Services for UNIX, that you mention. Still not without quirks.
WSL took off, because given the experience on OS X, where devs buy Apple expecting GNU/Linux instead of POSIX, Microsoft took the right decision to offer GNU/Linux right from the start instead of yet another POSIX attempt.
By the time WSL came to be, it was already a standard practice to use Virtual Box or VMWare workstation instead of mingw/cygwin, so even better not having to install them.
Ironically I learnt UNIX on Xenix, when it was still sold by Microsoft, maybe they should have kept it.
> I also don't quite get why one would want such a setup
Because LLMs are trained on UNIX-style shell usage and, in general, much more competent and efficient at using that over PowerShell or Batch/CMD. They want agents to run natively on Windows out of the box instead of through some compatibility layer.
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.
My guess is that some commands are compatible because they behave the same on both systems when used without command line options, and the implementation can distinguish between DOS and Unix options.
Otherwise just don't do it, if it is going to be a mess to work with.