Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coreutils for Windows

github.com

Post reply on HN
Print view View original

161–170 of 260 posts

Re: Coreutils for Windows

#161

Post by forrestthewoods »

yjftsjthsd-h wrote: post #151
forrestthewoods wrote: post #135

Earlier quoted context omitted.

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…

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

Re: Coreutils for Windows

#162

Post by recursive »

badc0ffee wrote: post #134
0cf8612b2e1e wrote: post #93

Earlier quoted context omitted.

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

Re: Coreutils for Windows

#163

Post by trinix912 »

rfgplk wrote: post #39
pjmlp wrote: post #24

Earlier quoted context omitted.

No idea, this is broken at start, I would expect at least a reasoning on how they expect to improve the mess going forward. Otherwise just don't do it, if it is going to be a mess to work with.

There's almost no point to this, especially since they're already shipping a (strictly) limited subset with the reasoning "not useful on Windows" despite Windows equivalent facilities _clearly_ existing. They should have at least considered a full native port.

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.

Re: Coreutils for Windows

#164

Post by layer8 »

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?

How do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?

Re: Coreutils for Windows

#165

Post by Longhanks »

Someone1234 wrote: post #68
p-t wrote: post #34

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.

The question is not odd at all. Windows 10 Enterprise LTSC 2019 is supported until 2029: https://learn.microsoft.com/en-us/lifecycle/products/windows...

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.

Re: Coreutils for Windows

#166

Post by okanat »

rzzzt wrote: post #128
pipes wrote: post #96

Earlier quoted context omitted.

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

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.

Re: Coreutils for Windows

#167

Post by pjmlp »

layer8 wrote: post #164
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?

How do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?

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.

Re: Coreutils for Windows

#168

Post by yjftsjthsd-h »

justsomehnguy wrote: post #159
yjftsjthsd-h wrote: post #151

Earlier quoted context omitted.

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

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

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.

Re: Coreutils for Windows

#169

Post by rzzzt »

okanat wrote: post #166
rzzzt wrote: post #128

Earlier quoted context omitted.

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

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

I did forget about these! The installer will add separate launchers for each style of environment.

Re: Coreutils for Windows

#170

Post by layer8 »

zahllos wrote: post #100
chasil wrote: post #85

Earlier quoted context omitted.

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…

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.
Post reply on HN