Rendered at 12:53:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jakegmaths 19 hours ago [-]
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.
chasil 19 hours ago [-]
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."
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.
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 :-)
yjftsjthsd-h 17 hours ago [-]
> 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
okanat 16 hours ago [-]
Linux kernel's ABI/API surface is completely byte-based and is tiny compared to Win32 API. The stable ABI of Windows is strictly in the user space and it covers the entire useful operating system. Don't forget that glibc isn't that ABI stable nor anything that goes all the way up to systemd/X11/gettext/Wayland/cairo/GTK/Qt/glade/Pipewire/xdg. Nothing equivalent in Linux environment is stable, especially compared against Win32 system libraries.
You encounter encoding requirements not in kernel system calls but in more user-facing sides of the OS. So your comparison should include all the userspace components of a Linux system (e.g. gettext), if you're considering the places where you encounter actual Unicode string-based operations where UTF-16 comes into play in Windows.
ALL OF THE equivalent Windows libraries (user32.dll, kernel32.dll, ws2_32.dll, shellex.dll ...) to the Linux ones I counted above and more are ABI and API stable.
yjftsjthsd-h 15 hours ago [-]
See, I was sympathetic to that view, except that they specifically posted
> We don't want the NT kernel to end up like Linux, after all
(Emphasis mine)
And that's... The one part of the OS where Linux is ABI stable.
okanat 14 hours ago [-]
I think they didn't mean Linux as in the kernel sense but in the overall "Family of OSes and ecosystem with very unstable APIs" sense.
zahllos 19 hours ago [-]
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.
layer8 16 hours ago [-]
The development of Windows NT based on UCS-2 precedes the RFC by roughly a decade, and little-endian was the natural choice for the Intel PC platform. Obviously the endianness had to remain the same when UCS-2 was extended to support UTF-16.
zahllos 2 hours ago [-]
Also true. The BOMs though are annoying.
Dwedit 19 hours ago [-]
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).
electroly 12 hours ago [-]
UTF-16 is the internal format of the ICU library (International Components for Unicode, the support library from the Unicode standards people) which is a common way to add "full fat" Unicode support to a programming language. This has knock-on effects everywhere. If you're using ICU, you either use UTF-16, too, or you constantly convert back and forth every time you interact with ICU. You're often best off using UTF-16 in memory and only converting to UTF-8 when you write files or transmit over the network.
wvenable 18 hours ago [-]
> 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.
bvanheu 16 hours ago [-]
> Windows is also a rare bird in UTF-16.
an interesting tidbit, some Windows kernel developer realized that most registry keys are ascii anyways so they could save up to 50% space simply by storing the name as ascii. The flag is called "compressed name" and they will pad with 0x00 when reading the name to make a proper utf-16 string.
pjmlp 19 hours ago [-]
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.
fg137 19 hours ago [-]
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.
0cf8612b2e1e 19 hours ago [-]
Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.
badc0ffee 18 hours ago [-]
At which layer? dir /w, for example, is never going to list the contents of \w.
pjmlp 7 hours ago [-]
All the layers, except applications where devs still look for the wrong slash manually.
OSes and modern programming languages have APIs for file navigation for a reason.
On Windows this implies old applications from another era, good old command window, or people that don't know better.
vips7L 15 hours ago [-]
The kernel and ntfs does not care about slash direction. Specific programs like dir might though and honestly if you're on windows just use powershell and avoid legacy cmd stuff.
pjmlp 7 hours ago [-]
Additionally on programming languages use the apis for path management, instead of explicit looking for the \ or / characters.
> ... 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.
The experience with Windows Services for UNIX wasn't that great, so yet another good product killed via acquisitions?
I only know it post acquisition.
dekhn 18 hours ago [-]
I ported a million-line, OpenGL/Motif application using Interix (before it was acquired). Indeed, it was grand.
rfgplk 19 hours ago [-]
> 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).
hnlmorg 5 hours ago [-]
> Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level).
The kernels undoubtedly take different approaches. But there's nothing in NT that strictly prohibits POSIX compatibility layers. As we see with the many compatibility layers that have existed for Windows over the years.
> For instance the idea that "everything is a file"
POSIX doesn't have a concept of "everything is a file". That's Plan 9. UNIX and POSIX actually made numerous concessions here and there are plenty of constructs that are not exposed as a file.
Windows does already abstract a few primitives as files too. In fact even DOS has the concept of device files, though in typical Microsoft fashion, it's implementation was a clusterfuck that took MS 40 years to fix.
> or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
NT uses an object system for filesystem objects, but it still has a root. As you can see in the WinObj (eg screenshot below)
The C:\ convention is really more there for compatibility with DOS-lineage software but the underlying filesystem APIs work fine with NT objects.
For example, C:\foo.txt might be equivalent to \Device\HarddiskVolume3\foo.txt
In this regard, it's similar to how POSIX has a database of inodes and the filesystem hierarchy is actually just an abstraction that sits on top of that
Grom_PE 19 hours ago [-]
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.
wnevets 19 hours ago [-]
> 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.
Measter 3 hours ago [-]
The only times I can remember having line-ending issues is using GNU's tools on Linux. Every Windows tool I can remember using accepts both CRLF and LF.
pipes 19 hours ago [-]
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.
dataflow 12 hours ago [-]
I think you want a .gitattributes file where you set the EOL of the file types you care about. And you might want to try autocrlf=input.
pipes 5 hours ago [-]
Thanks for this :)
layer8 16 hours ago [-]
A lot of tooling that generates or transform text-like files (e.g. XML) outputs native line endings, which in case of Windows is CRLF. Depending on what you do, it’s almost impossible to avoid that.
alok-g 12 hours ago [-]
>> Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes.
{To the extent such stuff is pragmatic:} I think we should switch to Pascal-style strings everywhere, and then have no need for having special-purpose characters like path separators (a path now being a list of strings).
pjmlp 7 hours ago [-]
Windows has been doing for quite a while, that is how COM strings work.
Night_Thastus 16 hours ago [-]
"Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes."
Hahahahaha. That's hillarious.
Oh god, you're serious?
Do you have any idea how much of Windows, and user software would break? Any idea at all?
You really want MS, who has built backwards compatibility as a core feature of Windows, to break countless thousands of pieces of software that run on it?
I'm sure there's some idealized fantasy in which that change gets wrapped in a neat little abstraction that prevents anything from breaking. I promise you, there is no way of encapsulating or abstracting that change that works for everyone.
If I could wave a magic wand and make it so without breaking it, I would. But it's a fantasy.
hnlmorg 5 hours ago [-]
> break countless thousands of pieces of software
I'd estimate millions
aniceperson 19 hours ago [-]
the two filesystems can be a super power... i seamlessly use the same driver between wsl2 and my dual booted opensuse.
thewebguyd 19 hours ago [-]
Yeah I don't mind/like the two file systems. Looks like MS is taking it further too they also announced WSL Containers & API.
sometimelurker 12 hours ago [-]
maybe windows should actually just become linux
saidnooneever 19 hours ago [-]
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!)
thewebguyd 19 hours ago [-]
> 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.
ACS_Solver 17 hours ago [-]
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.
pjmlp 6 hours ago [-]
Inspired by the ways of Xerox, Genera and ETHZ.
It can be verbose, but the object approach, and having .NET, DLLs and COM as first class primitives is quite flexible.
Naturally you can have a similar experience on UNIX, e.g. fish, but very few do it.
d3Xt3r 18 hours ago [-]
You can skip the `| Select` btw.
Just do `someoutput | ft ColumnName,ColumnName,CloumnName`
throwaway613746 19 hours ago [-]
[dead]
forrestthewoods 18 hours ago [-]
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.
yjftsjthsd-h 17 hours ago [-]
> 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.
Measter 3 hours ago [-]
Complete and utter nonsense. Every Windows tool I remember using has handled LF-only endings perfectly fine, meanwhile Linux tools regularly fail to handle CRLF endings.
justsomehnguy 17 hours ago [-]
> 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'.
yjftsjthsd-h 16 hours ago [-]
I didn't say it was the one and only True Way. My intended meaning - which I admit I may have poorly conveyed - is that tools from the unix ecosystem are intended to work on unix conventions, and do, and that works. Windows has different standards, which is also fine, but it follows that you shouldn't expect unix tools to follow Windows standards even if you make them run on Windows. This is like getting Windows software to run under WINE and then complaining that it doesn't use /n newlines and that it should change to accommodate Linux (or whatever). No, a Windows program will follow Windows standards even when made to run on a unix-like. And in the same way, unix-family software is going to follow unix standards even on Windows.
pjmlp 6 hours ago [-]
UNIX and Windows aren't the only OSes on the planet, even though UNIX folks tend to assume that.
Heck many mistake UNIX with GNU/Linux even, and then complain when given a UNIX that isn't a Linux distro.
CamperBob2 14 hours ago [-]
I think the point is that line endings are a really, really stupid hill for either Linux or Windows to die on. The day when any programs should have cared about line endings came and went decades ago.
forrestthewoods 15 hours ago [-]
Your entire framing is wrong imho.
Multi-platform is very easy and a solved problem if you try juuuust a tiny amount.
For example the Rust stdlib iterator for lines() handles both conventions. It just works. Very easy.
I live in a cross-platform world. Line endings in text files should not be a breaking problem because some CLI tool refuses to support both. That’s just plain bad software engineering.
I expect Unix tools that process text files to be capable of supporting text files that have different conventions. This is very easy. Refer to previous comments on stubbornness out of spite.
forrestthewoods 17 hours ago [-]
Comments like this really make me wish HN allowed you to block users. Alas.
yjftsjthsd-h 16 hours ago [-]
If you have something to say, say it. This is barely even an ad hominem.
cindyllm 16 hours ago [-]
[dead]
weregiraffe 19 hours ago [-]
>Windows really needs to ditch CRLF...
Windows needs to ditch itself.
avidphantasm 19 hours ago [-]
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.
Dwedit 19 hours ago [-]
Nobody wants to use \??\GLOBALROOT\Device\HarddiskVolume3\ in their paths.
avidphantasm 14 hours ago [-]
Nonsense. You can mount filesystems to mount points in much the same way as is done in Unix. No one would ever need to do that.
Dwedit 14 hours ago [-]
You can indeed use mount points like C:\mountdir, but that's still on the C drive, which is a drive letter. It's not "no drive letters".
avidphantasm 2 hours ago [-]
And if \ was an alias for C:\ this would just be \mountdir.
noselasd 19 hours ago [-]
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 ?
avidphantasm 14 hours ago [-]
It’s arcane and technical for no reason. /Users/ME/Documents, /Media/MyThumbDrive/…, etc. are much clearer and less confusing than C:\…
thewebguyd 12 hours ago [-]
At the very least, drive letters do make SMB shares a bit simpler for the non technical folks. T:\MyData is easier for them than \\0010-somehost-win.site1.mycorp.loca\Share01\MyData\
I used to support a group of completely tech illiterate users in construction & manufacturing. Them figuring out T:\ was hard enough, ask them to type in a UNC path into the address bar in explorer and you get "Wtf is file explorer? Wtf is an address bar? Where is the backslash key??"
avidphantasm 2 hours ago [-]
Or just use sane names like \\MyDivision\Share01\MyData and mount that to \Network\Share01 or some such.
piperswe 11 hours ago [-]
Then in this hypothetical world you could mount \\0010-somehost.win.site1.mycorp.local\Share01 to /Share01 rather than T:
pjmlp 19 hours ago [-]
> 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?
chasil 19 hours ago [-]
Fully-qualify the path to the target program, and it should be no concern.
pjmlp 19 hours ago [-]
What a great developer experience out of the box!
larkost 18 hours ago [-]
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/`?
qrobit 17 hours ago [-]
On nixos they're not, there's a single executable in /bin -- /bin/sh, and a single executable in /usr/bin -- /usr/bin/env
phs318u 14 hours ago [-]
Sounds like a case for GNU Autoconf and ./configure.
5 hours ago [-]
LoganDark 19 hours ago [-]
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
chasil 19 hours ago [-]
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.
d3Xt3r 18 hours ago [-]
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.
If non-POSIX features are required, the Android decision for mksh might suggest oksh for Windows.
GoblinSlayer 15 hours ago [-]
I guess, it's for yaml CI scripts.
justsomehnguy 17 hours ago [-]
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.
layer8 17 hours ago [-]
How do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?
pjmlp 17 hours ago [-]
The same way as cygwin, mingw?
Start a terminal session where they come first in the PATH?
That way one knows where they are getting into.
layer8 16 hours ago [-]
Well, you can have that now? Where is the problem?
pjmlp 8 hours ago [-]
The problem is that not only I have to manually do it myself, it is incomplete, quite the opposite of what is already out there.
In what sense is this half baked job supposed to be better?
ocdtrekkie 19 hours ago [-]
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!
zanecodes 18 hours ago [-]
Not that it detracts from your point, but PowerShell defined Linux-like aliases for PowerShell commands, not the old CMD.exe binaries.
So ls would actually match the behavior and accept the flags for Get-ChildItem, not dir.
scoopr 17 hours ago [-]
Maybe it’s for the llm tool use PATH?
That was the most plausible reason to even mention it, that I could think of.
dataflow 20 hours ago [-]
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?
pjmlp 19 hours ago [-]
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.
rfgplk 19 hours ago [-]
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.
trinix912 17 hours ago [-]
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.
thepasch 1 hours ago [-]
> 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.
That'd be my guess, at least.
pjmlp 6 hours ago [-]
You are missing part of the history,
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.
pjmlp 19 hours ago [-]
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".
lhecker 18 hours ago [-]
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%).
18 hours ago [-]
fg137 18 hours ago [-]
Users might as well just use msys2.
201984 19 hours ago [-]
AI said to do it.
lhecker 18 hours ago [-]
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.
dataflow 12 hours ago [-]
Echo doesn't conflict with the DOS command?
lhecker 2 hours ago [-]
Yup! echo is a CMD builtin and doesn't exist as a dedicated executable.
hex4def6 19 hours ago [-]
I think if it conflicts with a CMD command it's not shipped, but if it conflicts with a powershell command it's ok.
dataflow 12 hours ago [-]
Echo doesn't conflict with CMD?
layer8 16 hours ago [-]
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.
dataflow 12 hours ago [-]
Isn't echo different even without options?
fabiensanglard 19 hours ago [-]
I wonder if the motivation is to make Ai agents work better on Windows?
lhecker 19 hours ago [-]
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.
penguin_booze 18 hours ago [-]
Could come pre-installed with cygwin instead.
okanat 18 hours ago [-]
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.
18 hours ago [-]
FergusArgyll 19 hours ago [-]
For sure. I wonder how long until the agents learn about this though. At least a year, right?
eksu 18 hours ago [-]
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.
GMoromisato 19 hours ago [-]
Or you can tell your agent about it in one line of AGENTS.md.
ex1fm3ta 19 hours ago [-]
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.
jayd16 19 hours ago [-]
If that was sufficient wouldn't it just be easier to map to the Powershell commands directly?
AgentMasterRace 18 hours ago [-]
Claude code (at least the cli) has this, their code leaked so you can see their extensive (1000+ LOC) PowerShell took script.
AgentMasterRace 18 hours ago [-]
Tool* (no edit button?)
EvanAnderson 19 hours ago [-]
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.
lhecker 18 hours ago [-]
> 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?
EvanAnderson 18 hours ago [-]
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.
e12e 18 hours ago [-]
I read the readme that way too - a table with included utils with conflict status, and a list of intenationally excluded utils.
"Note: Any command not mentioned is included in this suite. "
which I found quite confusing. It's a very large set, potentially infinite depending on what the universe of all commands is :)
You should link to the list of all the commands in your package.
ex1fm3ta 19 hours ago [-]
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.
NetMageSCW 19 hours ago [-]
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.
Voultapher 6 hours ago [-]
It's not seamless now is it if half the commands don't work.
Wine and other compatibility layers show that non-trivial software doesn't work if even one of the many layers uses something unsupported.
From the site, "there's some advantage in using the 64-bit executable busybox64.exe. In particular, it can be quite a bit faster."
EvanAnderson 19 hours ago [-]
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.
lhecker 18 hours ago [-]
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.
RachelF 17 hours ago [-]
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.
capitol_ 18 hours ago [-]
Why not use ripgrep?
EvanAnderson 18 hours ago [-]
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.
dovholuknf 20 hours ago [-]
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
signal11 18 hours ago [-]
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.
0x1d7 18 hours ago [-]
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.
okanat 16 hours ago [-]
NT kernel can and did implement POSIX. Multiple times even. That's how WSL1 works. NTFS can also support Unix-like permissions. There are ACLs for Owner and Group.
However, I'm not keen on using yet another Unix clone as well. At least Windows NT brought the world into 90s in the OS state-of-the-art where Unix clones are stuck in 80s and each of them patch around the deficiencies of POSIX. Native asynchronous APIs and truly object-oriented system call infrastructure is nowhere to be found in POSIX.
0x1d7 14 hours ago [-]
POSIX was implemented as a subsystem.
And it was never _fully_ implemented, as my post said. The NT kernel doesn't support certain POSIX semantics (fork).
The NT kernel does not understand fork(). You can-sorta-fake-it, which is what WSL1 did. There's no equivalent to fork() in any version of Windows. From your link:
> As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process.
The MSFT driver prepped something-like-fork and then called the native NtCreateProcess, which does not implement anything like fork().
piperswe 11 hours ago [-]
Isn’t Win32 also implemented as a subsystem?
0x1d7 22 minutes ago [-]
Yes, but the Executive has a hard dependence on Win32 for service control.
yjftsjthsd-h 17 hours ago [-]
Surely WSL1 proves that it mostly can
NewsaHackO 20 hours ago [-]
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?
19 hours ago [-]
Octoth0rpe 16 hours ago [-]
The one in that section that kills me is the lack of `uname`. So you build a bunch of posix-compatible stuff, note that some things will be missing and some work slightly differently. It sure would be nice if we had a standard way of telling which kind of system you were on then, WOULDN'T IT?? (a very common use case for uname)
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)
neskorodev 19 hours ago [-]
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.
andai 19 hours ago [-]
I think SSDs also randomize where data ends up? But I'm not sure if that's true for existing files too.
orev 19 hours ago [-]
Yes. All of the assumptions made with shred and sdelete apply only for spinning HDDs. SSDs require different methods of wiping.
FergusArgyll 19 hours ago [-]
Is there no way to track down where the data actually lives?
orev 19 hours ago [-]
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.
wtallis 19 hours ago [-]
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.
wtallis 19 hours ago [-]
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.
ChocolateGod 20 hours ago [-]
I assume it requires something exposed by the underlying filesystem.
kmeisthax 19 hours ago [-]
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.
ilotoki0804 19 hours ago [-]
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.
Always wondered if git bash was cygwin, I don't think it is, but it seems very similar.
rzzzt 18 hours ago [-]
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...
okanat 17 hours ago [-]
You're conflating MSYS2 with Mingw-w64. MSYS2 installation comes with multiple environments/ABIs and MSYS2 mode is actually a fork of Cygwin. They fork Cygwin, put some patches on and rename the DLL as msys-2.0.dll . Here is the sources for MSYS2 runtime that produces it: https://github.com/msys2/msys2-runtime . To run bash you need termios API, stty, fork, exec and signals (and some other POSIX-specific funtions).
Due to Windows's execution model it is not possible to natively implement fork. Cygwin implements those via a executable backdoor hack. Basically the executable starts executing from the usual start point and it receives where to jump via a named pipe. Since MSYS2 is a fork it uses the same implementation.
Unlike Cygwin, MSYS2's goal isn't to be a complete system but ship just enough tooling to enable development with Mingw-w64. Mingw-w64 is the toolchain that ships GCC and it also defines its own ABI where the C ABI is the same as MSVC / Win32 ABI except that Mingw-ABI comes with its own threading and structured exception handling infrastructure. For C++ Mingw-w32 uses Itanium ABI instead of MSVC. If you use GCC to compile the debugging symbols will be DWARF with Mingw-32.
You can also use Clang environments where you can generate PDB debug symbols and use native Win32 threading.
Except for the differences above, the executables targetting Mingw-w64 ABI are normal native Windows executables. They don't have access to most of the unistd.h and they have to use native Windows system calls (kernel32.dll user32.dll, ucrt etc.)
You can target MSYS2 / Cygwin ABI too (just like Bash). In this ABI the entire system works like a POSIX system. Unlike Mingw-w64 backslashes are not native. In MSYS2-ABI programs execute very slowly compared to purely Mingw-w64 executables since they always have to pass the POSIX emulation layer.
rzzzt 16 hours ago [-]
I did forget about these! The installer will add separate launchers for each style of environment.
okanat 16 hours ago [-]
Git Bash is an MSYS2 environment that ships `bash.exe`. The rest of the Git-for-Windows executables are native Windows executables compiled with Mingw-w64 (aka GCC for Windows). Except for Bash nothing runs under POSIX simulation provided by MSYS2 runtime. MSYS2 runtime is a fork of Cygwin.
Any command not listed under the "Shell conflicts" section is included. In my testing `ln` works great.
natas 19 hours ago [-]
No thanks, I'd rather use linux.
lousken 12 hours ago [-]
ReFS -> ZFS
Remove batch, VBS and switch from powershell 5 to 7, add bash
Replace DSC in favour of Ansible
Remove windows registries
Switch to systemd for services
Rename folders like Users to home, programdata to etc, program files to opt, store/winget apps /usr
and call it microsoft linux server hybrid
Dwedit 18 hours ago [-]
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.
okanat 15 hours ago [-]
Did you mean: Powershell or nushell
p-t 19 hours ago [-]
Is this only on windows 11 or does it support 10 as well? (i cant access the site rn because of wifi)
Someone1234 19 hours ago [-]
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.
Also, MS does absolutely support EoL versions of their OS - it took MSVC's STL until 2024 to finally drop support for Windows 7 (whose final ESU update was 2023): https://github.com/microsoft/STL/issues/4858 - it isn't unlikely that they (STL maintainers) are not going to get approval for dropping Windows 10 support before 2029.
lhecker 18 hours ago [-]
It should work on Windows 10. If you're using PowerShell, you do need to have v7.4 or later installed, however.
testdelacc1 19 hours ago [-]
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.
Apparently the creator of the fork is also a maintainer of some uutils repositories.
NetMageSCW 19 hours ago [-]
So “supports Windows” doesn’t mean supports Windows.
egorfine 18 hours ago [-]
The original one is not virtue signaling enough
Havoc 20 hours ago [-]
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
thewebguyd 19 hours ago [-]
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.
Havoc 12 hours ago [-]
Thanks. Wasn’t aware of gip
NetMageSCW 19 hours ago [-]
ipconfig works pretty well.
thedumbname 19 hours ago [-]
Microsoft provides an awesome problem-solving solution, and 0 of the 6 problems they listed in the 'Windows caveats' section are solved.
gigel82 20 hours ago [-]
Native Coreutils for Windows is genuinely some good news coming from Microsoft.
zamadatix 20 hours ago [-]
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.
thewebguyd 19 hours ago [-]
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.
xeonmc 19 hours ago [-]
Hopefully these do not require a PhD to be implemented.
cute_boi 19 hours ago [-]
With these AI agents using lot of linux commands, I think they have to do it.
egorfine 18 hours ago [-]
It's not coreutils. It's a rust slop.
jeff_carr 18 hours ago [-]
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.
thewebguyd 17 hours ago [-]
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
aniceperson 19 hours ago [-]
they should give up on the backwards slash.
19 hours ago [-]
dekhn 18 hours ago [-]
Linux: first they laugh at you, then it embraces, extends, and extuinguishes Windows.
yyyk 13 hours ago [-]
WSL1 is generally better for these usecases.
rfgplk 19 hours ago [-]
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?
asveikau 19 hours ago [-]
I just have msys on my PATH.
egorfine 18 hours ago [-]
Yeah, we don't hate this uutils (NOT coreutils) project enough.
mx7zysuj4xew 9 hours ago [-]
Not sure of it's sarcasm, but you'd be right, everyone involved with this garbage should be banned from IT forever
egorfine 3 hours ago [-]
It's not sarcasm. I truly believe that uutils exist solely for virtue signaling purposes and for better license for corporate (Canonical).
hs86 19 hours ago [-]
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.
spidercat 19 hours ago [-]
What does this do that Cygwin doesn't?
okanat 16 hours ago [-]
Cygwin is like Wine. It fully emulates POSIX and puts a filesystem and syscall emulation layer on top and even an emulation for `/dev`. uutils are strictly limited to what Windows provides natively.
stronglikedan 18 hours ago [-]
this conflicts with native shell utilities of the same name - take that, cygwin!
I thought it was just a distro added alias like how some systems used to have '..' for 'cd ..'
tonymet 16 hours ago [-]
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.
doctorpangloss 19 hours ago [-]
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.
mx7zysuj4xew 9 hours ago [-]
BusyBox IS NOT COREUTILS. ITS NOT EVEN REMOTELY THE SQME THING. It's something entirely different and not even remotely an adequate replacement
shevy-java 19 hours ago [-]
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.
19 hours ago [-]
raggi 20 hours ago [-]
uutils coreutils was/is already available and more complete than this
19 hours ago [-]
NetMageSCW 19 hours ago [-]
citation needed
raggi 15 hours ago [-]
Wat?
winget install uutils.coreutils
adzm 19 hours ago [-]
Finally, tee in the command prompt. I want to like powershell but the way it handles [] in filenames has bitten me so many times and fixing it turns simple things into verbose LiteralPath incantations
natas 18 hours ago [-]
100% vibe coded.
compiler-devel 17 hours ago [-]
Ok
rvz 20 hours ago [-]
Exactly. The best Linux distro is Windows.
19 hours ago [-]
FergusArgyll 19 hours ago [-]
The case for that statement (if there's a case at all) is wsl. This is outside wsl.
rvz 11 hours ago [-]
It is still on Windows. No need to install Linux on the machine at all.
throwatdem12311 19 hours ago [-]
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.
snvzz 9 hours ago [-]
MIT is a good license to maximize proliferation of use.
It seems to be working as intended for uutils.
throwatdem12311 41 minutes ago [-]
As if being popular by itself is actually a good thing. Popular with corporate shitheads that want free stuff and not contribute anything sure. Is it good for Open Source, absolutey not.
rvz 19 hours ago [-]
It was really obvious.
Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.
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."
https://en.wikipedia.org/wiki/UTF-16
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 :-)
I think you're making a joke, but it still doesn't make sense. Linux does avoid breaking changes to its userspace ABI
You encounter encoding requirements not in kernel system calls but in more user-facing sides of the OS. So your comparison should include all the userspace components of a Linux system (e.g. gettext), if you're considering the places where you encounter actual Unicode string-based operations where UTF-16 comes into play in Windows.
ALL OF THE equivalent Windows libraries (user32.dll, kernel32.dll, ws2_32.dll, shellex.dll ...) to the Linux ones I counted above and more are ABI and API stable.
> We don't want the NT kernel to end up like Linux, after all
(Emphasis mine)
And that's... The one part of the OS where Linux is ABI stable.
Worse are the byte order marks required to support both endians that end up in files.
Web browsers use UTF-16 internally. So Windows isn't even largest "platform" that uses UTF-16.
an interesting tidbit, some Windows kernel developer realized that most registry keys are ascii anyways so they could save up to 50% space simply by storing the name as ascii. The flag is called "compressed name" and they will pad with 0x00 when reading the name to make a proper utf-16 string.
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.
OSes and modern programming languages have APIs for file navigation for a reason.
On Windows this implies old applications from another era, good old command window, or people that don't know better.
Get-ChildItem /w
[0] https://www.youtube.com/watch?v=bC6tngl0PTI
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 only know it post acquisition.
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).
The kernels undoubtedly take different approaches. But there's nothing in NT that strictly prohibits POSIX compatibility layers. As we see with the many compatibility layers that have existed for Windows over the years.
> For instance the idea that "everything is a file"
POSIX doesn't have a concept of "everything is a file". That's Plan 9. UNIX and POSIX actually made numerous concessions here and there are plenty of constructs that are not exposed as a file.
Windows does already abstract a few primitives as files too. In fact even DOS has the concept of device files, though in typical Microsoft fashion, it's implementation was a clusterfuck that took MS 40 years to fix.
> or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
NT uses an object system for filesystem objects, but it still has a root. As you can see in the WinObj (eg screenshot below)
https://learn.microsoft.com/en-us/sysinternals/downloads/med...
The C:\ convention is really more there for compatibility with DOS-lineage software but the underlying filesystem APIs work fine with NT objects.
For example, C:\foo.txt might be equivalent to \Device\HarddiskVolume3\foo.txt
In this regard, it's similar to how POSIX has a database of inodes and the filesystem hierarchy is actually just an abstraction that sits on top of that
The only places that still forced CRLF were batch files and clipboard.
That has been my experience as well. I can't remember the last time I had an issue related to CRLF.
{To the extent such stuff is pragmatic:} I think we should switch to Pascal-style strings everywhere, and then have no need for having special-purpose characters like path separators (a path now being a list of strings).
Hahahahaha. That's hillarious.
Oh god, you're serious?
Do you have any idea how much of Windows, and user software would break? Any idea at all?
You really want MS, who has built backwards compatibility as a core feature of Windows, to break countless thousands of pieces of software that run on it?
I'm sure there's some idealized fantasy in which that change gets wrapped in a neat little abstraction that prevents anything from breaking. I promise you, there is no way of encapsulating or abstracting that change that works for everyone.
If I could wave a magic wand and make it so without breaking it, I would. But it's a fantasy.
I'd estimate millions
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!)
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.
It can be verbose, but the object approach, and having .NET, DLLs and COM as first class primitives is quite flexible.
Naturally you can have a similar experience on UNIX, e.g. fish, but very few do it.
Just do `someoutput | ft ColumnName,ColumnName,CloumnName`
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.
The Linux ecosystem handles it fine (by using a single standard). Windows 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'.
Heck many mistake UNIX with GNU/Linux even, and then complain when given a UNIX that isn't a Linux distro.
Multi-platform is very easy and a solved problem if you try juuuust a tiny amount.
For example the Rust stdlib iterator for lines() handles both conventions. It just works. Very easy.
I live in a cross-platform world. Line endings in text files should not be a breaking problem because some CLI tool refuses to support both. That’s just plain bad software engineering.
I expect Unix tools that process text files to be capable of supporting text files that have different conventions. This is very easy. Refer to previous comments on stubbornness out of spite.
Windows needs to ditch itself.
I used to support a group of completely tech illiterate users in construction & manufacturing. Them figuring out T:\ was hard enough, ask them to type in a UNC path into the address bar in explorer and you get "Wtf is file explorer? Wtf is an address bar? Where is the backslash key??"
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?
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/`?
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
... 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.
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.
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.
Start a terminal session where they come first in the PATH?
That way one knows where they are getting into.
In what sense is this half baked job supposed to be better?
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!
So ls would actually match the behavior and accept the flags for Get-ChildItem, not dir.
That was the most plausible reason to even mention it, that I could think of.
Otherwise just don't do it, if it is going to be a mess to work with.
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.
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.
That'd be my guess, at least.
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.
"Yo make some UNIX stuff to show at BUILD as developer tools".
uutils enables fully Windows native commands in the subset of system calls and disk structure Windows supports.
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.
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.
The project includes all of those. Or were you talking about the past?
A gigantic idiot. Sorry.
But the rest are in there:
https://github.com/microsoft/coreutils/blob/3fa7aaf832ffc81d...
"Note: Any command not mentioned is included in this suite. "
which I found quite confusing. It's a very large set, potentially infinite depending on what the universe of all commands is :)
You should link to the list of all the commands in your package.
Wine and other compatibility layers show that non-trivial software doesn't work if even one of the many layers uses something unsupported.
winget install -e --id frippery.busybox-w32
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.
This is one of the few features that Linux file systems do not have.
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.
And that would suck.
However, I'm not keen on using yet another Unix clone as well. At least Windows NT brought the world into 90s in the OS state-of-the-art where Unix clones are stuck in 80s and each of them patch around the deficiencies of POSIX. Native asynchronous APIs and truly object-oriented system call infrastructure is nowhere to be found in POSIX.
And it was never _fully_ implemented, as my post said. The NT kernel doesn't support certain POSIX semantics (fork).
> As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process.
The MSFT driver prepped something-like-fork and then called the native NtCreateProcess, which does not implement anything like fork().
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.
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.
More project information: https://gitforwindows.org/
Official download: https://git-scm.com/install/windows
Due to Windows's execution model it is not possible to natively implement fork. Cygwin implements those via a executable backdoor hack. Basically the executable starts executing from the usual start point and it receives where to jump via a named pipe. Since MSYS2 is a fork it uses the same implementation.
Unlike Cygwin, MSYS2's goal isn't to be a complete system but ship just enough tooling to enable development with Mingw-w64. Mingw-w64 is the toolchain that ships GCC and it also defines its own ABI where the C ABI is the same as MSVC / Win32 ABI except that Mingw-ABI comes with its own threading and structured exception handling infrastructure. For C++ Mingw-w32 uses Itanium ABI instead of MSVC. If you use GCC to compile the debugging symbols will be DWARF with Mingw-32.
You can also use Clang environments where you can generate PDB debug symbols and use native Win32 threading.
Except for the differences above, the executables targetting Mingw-w64 ABI are normal native Windows executables. They don't have access to most of the unistd.h and they have to use native Windows system calls (kernel32.dll user32.dll, ucrt etc.)
You can target MSYS2 / Cygwin ABI too (just like Bash). In this ABI the entire system works like a POSIX system. Unlike Mingw-w64 backslashes are not native. In MSYS2-ABI programs execute very slowly compared to purely Mingw-w64 executables since they always have to pass the POSIX emulation layer.
I explained the differences here: https://news.ycombinator.com/item?id=48375716
https://github.com/rmyorston/busybox-w32
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).
https://www.gnu.org/software/coreutils/manual/html_node/ln-i...
https://uutils.github.io/coreutils/docs/utils/ln.html
Remove batch, VBS and switch from powershell 5 to 7, add bash
Replace DSC in favour of Ansible
Remove windows registries
Switch to systemd for services
Rename folders like Users to home, programdata to etc, program files to opt, store/winget apps /usr
and call it microsoft linux server hybrid
Also, MS does absolutely support EoL versions of their OS - it took MSVC's STL until 2024 to finally drop support for Windows 7 (whose final ESU update was 2023): https://github.com/microsoft/STL/issues/4858 - it isn't unlikely that they (STL maintainers) are not going to get approval for dropping Windows 10 support before 2029.
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.
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
> 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.
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.
If they just kicked them out and left the Windows div alone it'd be a decent OS. All the bones are there.
The project will deny it, but this is clearly an attack against the GPL
https://www.gnu.org/software/coreutils/manual/html_node/dir-...
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.
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.
winget install uutils.coreutils
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 seems to be working as intended for uutils.
Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.