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

141–150 of 260 posts

Re: Coreutils for Windows

#141

Post by zanecodes »

ocdtrekkie wrote: post #83
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?

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!

Not that it detracts from your point, but PowerShell defined Linux-like aliases for PowerShell commands, not the old CMD.exe binaries.

So ls would actually match the behavior and accept the flags for Get-ChildItem, not dir.

Re: Coreutils for Windows

#142

Post by 0x1d7 »

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.

Re: Coreutils for Windows

#143

Post by EvanAnderson »

capitol_ wrote: post #133
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?

I'm working with mostly "cattle"-type boxes with only the stock OS components installed so I "live off the land". On boxes that I treat as "pets" I do load other tools. A Win32 port of GNU grep has done well enough for me that I've never thought to look at ripgrep.

Re: Coreutils for Windows

#144

Post by jeff_carr »

egorfine wrote: post #109
gigel82 wrote: post #2

Native Coreutils for Windows is genuinely some good news coming from Microsoft.

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.

Re: Coreutils for Windows

#145

Post by okanat »

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.

Cygwin isn't native Windows. Cygwin does many unholy things to enable signals and fork syscall in binaries.

uutils enables fully Windows native commands in the subset of system calls and disk structure Windows supports.

Re: Coreutils for Windows

#146

Post by larkost »

pjmlp wrote: post #99
chasil wrote: post #81

Earlier quoted context omitted.

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

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 make fully-qualified paths possibly a nightmare. Anyone know if these get put at `/bin/`?

Re: Coreutils for Windows

#147

Post by lhecker »

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.

I apologize for asking, but did you also understood the "Shell conflicts" section as being the complete list of utilities? The project ships the majority of core utilities (~75%).

Re: Coreutils for Windows

#149

Post by yjftsjthsd-h »

0x1d7 wrote: post #131
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…

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

> 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

Post reply on HN