Coreutils for Windows • Hacker News Board

Re: Coreutils for Windows

#241

Post by zahllos » Wed, Jun 03, 2026, 10:56 AM UTC

layer8 wrote: post #170

zahllos wrote: post #100

Earlier quoted context omitted.

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.

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.

Also true. The BOMs though are annoying.

Re: Coreutils for Windows

#242

Post by thepasch » Wed, Jun 03, 2026, 11:39 AM UTC

trinix912 wrote: post #163

rfgplk wrote: post #39

Earlier quoted context omitted.

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…

> 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.

Re: Coreutils for Windows

#243

Post by throwatdem12311 » Wed, Jun 03, 2026, 12:12 PM UTC

snvzz wrote: post #218

throwatdem12311 wrote: post #22

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.

MIT is a good license to maximize proliferation of use. It seems to be working as intended for uutils.

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.

Re: Coreutils for Windows

#244

Post by 0x1d7 » Wed, Jun 03, 2026, 12:31 PM UTC

piperswe wrote: post #215

0x1d7 wrote: post #195

Earlier quoted context omitted.

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).

Isn’t Win32 also implemented as a subsystem?

Yes, but the Executive has a hard dependence on Win32 for service control.

Re: Coreutils for Windows

#245

Post by Jotalea » Wed, Jun 03, 2026, 1:25 PM UTC

what's the difference between these and the ones distributed in git for windows?

Re: Coreutils for Windows

#246

Post by wnevets » Wed, Jun 03, 2026, 2:51 PM UTC

pipes wrote: post #102

wnevets wrote: post #70

Earlier quoted context omitted.

> 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.

does visual studio support editorconfig.org? I use end_of_line = lf for all my projects

Re: Coreutils for Windows

#247

Post by dataflow » Wed, Jun 03, 2026, 3:16 PM UTC

lhecker wrote: post #240

dataflow wrote: post #210

Earlier quoted context omitted.

Echo doesn't conflict with the DOS command?

Yup! echo is a CMD builtin and doesn't exist as a dedicated executable.

Sorry, I'm not following the logic. Isn't the same true for dir?

Re: Coreutils for Windows

#248

Post by Tobu » Wed, Jun 03, 2026, 3:56 PM UTC

pjmlp wrote: post #12

> 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?

In the case of find and sort, the command invoked also depends on argument sniffing, with a fallback through the registry when that is indecisive: https://github.com/microsoft/coreutils/blob/main/src/nthelpe...

Re: Coreutils for Windows

#249

Post by Tobu » Wed, Jun 03, 2026, 4:02 PM UTC

lhecker wrote: post #240

dataflow wrote: post #210

Earlier quoted context omitted.

Echo doesn't conflict with the DOS command?

Yup! echo is a CMD builtin and doesn't exist as a dedicated executable.

Is there a list of CMD builtins somewhere?

Re: Coreutils for Windows

#250

Post by [deleted] » Wed, Jun 03, 2026, 4:50 PM UTC

okanat wrote: post #183

yjftsjthsd-h wrote: post #149

Earlier quoted context omitted.

> 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

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 agai…

[deleted]