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

171–180 of 260 posts

Re: Coreutils for Windows

#171

Post by yjftsjthsd-h »

forrestthewoods wrote: post #161
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.

Comments like this really make me wish HN allowed you to block users. Alas.

If you have something to say, say it. This is barely even an ad hominem.

Re: Coreutils for Windows

#172

Post by layer8 »

Grom_PE wrote: post #63
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…

On Windows, I've mostly avoided CRLF by configuring text editors and git to use LF, and writing text files in binary mode. The only places that still forced CRLF were batch files and clipboard.

A lot of tooling that generates or transform text-like files (e.g. XML) outputs native line endings, which in case of Windows is CRLF. Depending on what you do, it’s almost impossible to avoid that.

Re: Coreutils for Windows

#173

Post by Octoth0rpe »

NewsaHackO wrote: post #4

In the intentionally dropped section, it lists shed as "Not particularly useful on Windows." Does anyone know why? Is thre already a shred-like command in Windows?

The one in that section that kills me is the lack of `uname`. So you build a bunch of posix-compatible stuff, note that some things will be missing and some work slightly differently. It sure would be nice if we had a standard way of telling which kind of system you were on then, WOULDN'T IT?? (a very common use case for uname)

Re: Coreutils for Windows

#174

Post by Night_Thastus »

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 really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes."

Hahahahaha. That's hillarious.

Oh god, you're serious?

Do you have any idea how much of Windows, and user software would break? Any idea at all?

You really want MS, who has built backwards compatibility as a core feature of Windows, to break countless thousands of pieces of software that run on it?

I'm sure there's some idealized fantasy in which that change gets wrapped in a neat little abstraction that prevents anything from breaking. I promise you, there is no way of encapsulating or abstracting that change that works for everyone.

If I could wave a magic wand and make it so without breaking it, I would. But it's a fantasy.

Re: Coreutils for Windows

#175

Post by layer8 »

dataflow wrote: post #6

So dir is not shipped due to conflict with built-ins, echo and rmdir are shipped despite conflicts, and sort is deemed not to have a conflict? What is the logic?

My guess is that some commands are compatible because they behave the same on both systems when used without command line options, and the implementation can distinguish between DOS and Unix options.

Re: Coreutils for Windows

#176

Post by okanat »

pipes wrote: post #96
ilotoki0804 wrote: post #84

You can install gnu-compative shell commands when installing git for Windows. It even includes useful unix utilites like bash, so check it out if you're interested. More project information: https://gitforwindows.org/ Official download: https://git-scm.com/install/windows

Always wondered if git bash was cygwin, I don't think it is, but it seems very similar.

Git Bash is an MSYS2 environment that ships `bash.exe`. The rest of the Git-for-Windows executables are native Windows executables compiled with Mingw-w64 (aka GCC for Windows). Except for Bash nothing runs under POSIX simulation provided by MSYS2 runtime. MSYS2 runtime is a fork of Cygwin.

I explained the differences here: https://news.ycombinator.com/item?id=48375716

Re: Coreutils for Windows

#177

Post by layer8 »

pjmlp wrote: post #167
layer8 wrote: post #164

Earlier quoted context omitted.

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.

Well, you can have that now? Where is the problem?

Re: Coreutils for Windows

#178

Post by okanat »

spidercat wrote: post #92

What does this do that Cygwin doesn't?

Cygwin is like Wine. It fully emulates POSIX and puts a filesystem and syscall emulation layer on top and even an emulation for `/dev`. uutils are strictly limited to what Windows provides natively.

Re: Coreutils for Windows

#179

Post by bvanheu »

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…

> Windows is also a rare bird in UTF-16.

an interesting tidbit, some Windows kernel developer realized that most registry keys are ascii anyways so they could save up to 50% space simply by storing the name as ascii. The flag is called "compressed name" and they will pad with 0x00 when reading the name to make a proper utf-16 string.

Re: Coreutils for Windows

#180

Post by okanat »

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.

NT kernel can and did implement POSIX. Multiple times even. That's how WSL1 works. NTFS can also support Unix-like permissions. There are ACLs for Owner and Group.

However, I'm not keen on using yet another Unix clone as well. At least Windows NT brought the world into 90s in the OS state-of-the-art where Unix clones are stuck in 80s and each of them patch around the deficiencies of POSIX. Native asynchronous APIs and truly object-oriented system call infrastructure is nowhere to be found in POSIX.

Post reply on HN