Live data from Hacker News

Coreutils for Windows

github.com

81–90 of 260 posts

Re: Coreutils for Windows

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

Fully-qualify the path to the target program, and it should be no concern.

Re: Coreutils for Windows

#82
post #81
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?

Fully-qualify the path to the target program, and it should be no concern.

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

Re: Coreutils for Windows

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

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!

Re: Coreutils for Windows

#85

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

Windows is also a rare bird in UTF-16.

"UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.

"UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII. It has never gained popularity on the web, where it is declared by under 0.004% of public web pages (and even then, the web pages are most likely also using UTF-8). UTF-8, by comparison, gained dominance years ago and accounted for 99% of all web pages by 2025."

https://en.wikipedia.org/wiki/UTF-16

Re: Coreutils for Windows

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

Re: Coreutils for Windows

#87
post #81

Earlier quoted context omitted.

Fully-qualify the path to the target program, and it should be no concern.

A big part of the point is so you can use scripts made for other platforms on windows natively, which you lose when you have to alter them to pass absolute paths

Busybox helps you avoid this nicely on Windows. When you run one of one of its shells, it uses all it's own builtins in preference to anything external.

Get the 64-bit version: "there's some advantage in using the 64-bit executable busybox64.exe. In particular, it can be quite a bit faster."

https://frippery.org/busybox/index.html

Re: Coreutils for Windows

#88

A fair question is why this fork of coreutils is required when the original Rust rewrite ( https://github.com/uutils/coreutils/ ) supports Windows, in addition to Linux, macOS and wasm. The reason seems to be a few windows specific fixes ( https://github.com/uutils/coreutils/compare/main...microsoft... ) which can probably be upstreamed into the main repo.

So “supports Windows” doesn’t mean supports Windows.

Re: Coreutils for Windows

#90

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

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

[dead]
Post reply on HN