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

151–160 of 260 posts

Re: Coreutils for Windows

#151

Post by yjftsjthsd-h »

forrestthewoods wrote: post #135
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…

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

Re: Coreutils for Windows

#152

Post by yjftsjthsd-h »

0x1d7 wrote: post #142
signal11 wrote: post #106

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.

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.

Surely WSL1 proves that it mostly can

Re: Coreutils for Windows

#153

Post by ACS_Solver »

thewebguyd wrote: post #78
saidnooneever wrote: post #48

Earlier quoted context omitted.

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…

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

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.

Re: Coreutils for Windows

#154

Post by qrobit »

larkost wrote: post #146
pjmlp wrote: post #99

Earlier quoted context omitted.

What a great developer experience out of the box!

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…

On nixos they're not, there's a single executable in /bin -- /bin/sh, and a single executable in /usr/bin -- /usr/bin/env

Re: Coreutils for Windows

#155

Post by thewebguyd »

jeff_carr wrote: post #144
egorfine wrote: post #109

Earlier quoted context omitted.

It's not coreutils. It's a rust slop.

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.

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

Re: Coreutils for Windows

#156

Post by scoopr »

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?

Maybe it’s for the llm tool use PATH?

That was the most plausible reason to even mention it, that I could think of.

Re: Coreutils for Windows

#157

Post by justsomehnguy »

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

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.

Re: Coreutils for Windows

#158

Post by chasil »

d3Xt3r wrote: post #140
LoganDark wrote: post #82

Earlier quoted context omitted.

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…

Bash itself is an odd duck in scripting, with some dark historical crevices: http://tiswww.case.edu/~chet/bash/POSIX

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.

Re: Coreutils for Windows

#159

Post by justsomehnguy »

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.

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

Re: Coreutils for Windows

#160

Post by RachelF »

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…

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.

Post reply on HN