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

131–140 of 260 posts

Re: Coreutils for Windows

#131

Post by 0x1d7 »

chasil wrote: post #85
jakegmaths wrote: post #30

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…

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.

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

Re: Coreutils for Windows

#133

Post by capitol_ »

EvanAnderson wrote: post #65

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…

Why not use ripgrep?

Re: Coreutils for Windows

#134

Post by badc0ffee »

0cf8612b2e1e wrote: post #93
jakegmaths wrote: post #30

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…

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.

Re: Coreutils for Windows

#135

Post by forrestthewoods »

jakegmaths wrote: post #30

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…

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.

Re: Coreutils for Windows

#136

Post by [deleted] »

penguin_booze wrote: post #125
lhecker wrote: post #101

Earlier quoted context omitted.

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.

Could come pre-installed with cygwin instead.

[deleted]

Re: Coreutils for Windows

#138

Post by lhecker »

omoikane wrote: post #132

What about "ln" (make symbolic links)? https://www.gnu.org/software/coreutils/manual/html_node/ln-i... https://uutils.github.io/coreutils/docs/utils/ln.html

Any command not listed under the "Shell conflicts" section is included. In my testing `ln` works great.

Re: Coreutils for Windows

#139

Post by [deleted] »

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.

[deleted]

Re: Coreutils for Windows

#140

Post by d3Xt3r »

LoganDark wrote: post #82
chasil wrote: 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

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.

Post reply on HN