Coreutils for Windows

by gigel82 • 2 months ago

227 247 2 months ago

gigel82• 2 months ago

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

zamadatix• 2 months ago

The command line team has been doing some solid work for a while. I recognize lhecker from the also great wt & edit projects.

If you told me during the Windows 7 era the Windows CLI would not only be getting nice but getting pretty comfortable I would never have believed it.

thewebguyd6• 2 months ago

Yeah, the problem with Windows isn't the command line team, the problem is the marketing & sales div using windows to push every other MS service.

If they just kicked them out and left the Windows div alone it'd be a decent OS. All the bones are there.

xeonmc• 2 months ago

Hopefully these do not require a PhD to be implemented.

cute_boi• 2 months ago

With these AI agents using lot of linux commands, I think they have to do it.

egorfine4• 2 months ago

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

jeff_carr• 2 months ago

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.

NewsaHackO• 2 months ago

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?

ChocolateGod• 2 months ago

I assume it requires something exposed by the underlying filesystem.

kmeisthax• 2 months ago

No. Shred will "work" - as in, compile, run, and have the expected logical effects of ultimately removing the file from the directory index - on any filesystem backed by any block device. The problem is that overwriting any part of a file is not guaranteed to actually erase the overwritten data. Actually, it never has been; shred is kind of a hack that assumes an overwriting file system driver and a block device dumb enough to not remap sectors writing to media that's intrinsically erasable. e.g. try running shred on a mounted CD-R and see how far that gets you.

neskorodev• 2 months ago

From shred man:

The shred command relies on a crucial assumption: that the file system and hardware overwrite data in place.

...

many modern file system designs do not satisfy this assumption. Exceptions include:

...

Log-structured or journaled file systems, such as.

...

NTFS.

andai• 2 months ago

I think SSDs also randomize where data ends up? But I'm not sure if that's true for existing files too.

Dwedit5• 2 months ago

Shred isn't very useful on SSDs in general. Because of TRIM, deleting a file instantly makes the sectors read back as 00 bytes. (Yes the data is technically still on the flash chips scattered across memory blocks without any mapping telling you where each piece of the data is, but is not readable through normal drive commands)

rzzzt3• 2 months ago

One possible alternative is cipher.exe: https://learn.microsoft.com/en-us/troubleshoot/windows-serve...

Octoth0rpe• 2 months ago

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)

dovholuknf• 2 months ago

FINALLY. This is actually exciting to me... Mind you the linux ports (cygwin, msys2, git bash) are all great to have and I make sure one version or the other is always on my path but having MS maintain them (assuming they continue to do so) is great news

dataflow6• 2 months ago

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?

2019842• 2 months ago

AI said to do it.

pjmlp15• 2 months ago

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.

rfgplk3• 2 months ago

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.

fg1372• 2 months ago

Users might as well just use msys2.

hex4def6• 2 months ago

I think if it conflicts with a CMD command it's not shipped, but if it conflicts with a powershell command it's ok.

dataflow6• 2 months ago

Echo doesn't conflict with CMD?

lhecker9• 2 months ago

As hex4def6 said, the idea was that DOS command conflicts are not a good idea, while overriding PowerShell builtins in interactive sessions (PSReadLine) is acceptable, if not a good idea. We open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics.

dataflow6• 2 months ago

Echo doesn't conflict with the DOS command?

layer85• 2 months ago

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.

dataflow6• 2 months ago

Isn't echo different even without options?

Havoc2• 2 months ago

Nice. I appreciate the effort to make things less painful for powerusers. I had noticed some of these working already in PS.

If anyone from MS is reading this can we please also get an equivalents (or even alias) for the thing that shows IP address? The windows equivalent of "ip a" is some convoluted PS command that I can never remember

thewebguyd6• 2 months ago

in PowerShell there is a built-in alias.

gip

You could also make your own alias if you specifically want to type "ip a" just add a powershell function to your $PROFILE. function ip { param($argument)...." etc. have it call Get-NetIPAddress, else fallback to ipconfig.

Havoc2• 2 months ago

Thanks. Wasn’t aware of gip

NetMageSCW5• 2 months ago

ipconfig works pretty well.

rvz3• 2 months ago

Exactly. The best Linux distro is Windows.

FergusArgyll3• 2 months ago

The case for that statement (if there's a case at all) is wsl. This is outside wsl.

rvz3• 2 months ago

It is still on Windows. No need to install Linux on the machine at all.

raggi2• 2 months ago

uutils coreutils was/is already available and more complete than this

NetMageSCW5• 2 months ago

citation needed

raggi2• 2 months ago

Wat?

winget install uutils.coreutils

pjmlp15• 2 months ago

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?

chasil7• 2 months ago

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

LoganDark2• 2 months ago

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

pjmlp15• 2 months ago

What a great developer experience out of the box!

ocdtrekkie• 2 months ago

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!

zanecodes• 2 months ago

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.

scoopr• 2 months ago

Maybe it’s for the llm tool use PATH?

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

layer85• 2 months ago

How do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?

pjmlp15• 2 months ago

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.

Tobu2• 2 months ago

In the case of find and sort, the command invoked also depends on argument sniffing, with a fallback through the registry when that is indecisive: https://github.com/microsoft/coreutils/blob/main/src/nthelpe...

testdelacc1• 2 months ago

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.

hootz• 2 months ago

Apparently the creator of the fork is also a maintainer of some uutils repositories.

NetMageSCW5• 2 months ago

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

egorfine4• 2 months ago

The original one is not virtue signaling enough

aniceperson2• 2 months ago

they should give up on the backwards slash.

fabiensanglard• 2 months ago

I wonder if the motivation is to make Ai agents work better on Windows?

FergusArgyll3• 2 months ago

For sure. I wonder how long until the agents learn about this though. At least a year, right?

ex1fm3ta2• 2 months ago

nope. With ClaudeCode you can create skills ( basically markdown instructions) to teach your agents what command to use. You can also update CLAUDE.md to inject custom instructions that are feeded anything ClaudeCode is started.

GMoromisato• 2 months ago

Or you can tell your agent about it in one line of AGENTS.md.

eksu• 2 months ago

Agents / models don't need to "learn" about this.

When on Windows, the models default to bash / coreutils conventions until they realize it doesn't work / not available unless explicitly instructed otherwise.

Even on Mac, they tend to default to bash instead of running things in zsh.

lhecker9• 2 months ago

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.

penguin_booze• 2 months ago

Could come pre-installed with cygwin instead.

throwatdem123114• 2 months ago

Was not expecting EEE for Coreutils but I suppose it’s the natural consequence of the MIT license used for uutils so not totally unexpected.

It’s annoying enough to support the differences between BSD and Linux, and now Linux has GNU and uutils, and now we’re gonna need Windows variant of uutils…ugh.

rvz3• 2 months ago

It was really obvious.

Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.

throwatdem123114• 2 months ago

Such a blatantly obvious attempt to damage GNU

snvzz4• 2 months ago

MIT is a good license to maximize proliferation of use.

It seems to be working as intended for uutils.

throwatdem123114• 2 months ago

As if being popular by itself is actually a good thing. Popular with corporate shitheads that want free stuff and not contribute anything sure. Is it good for Open Source, absolutey not.

2019842• 2 months ago

There's also a windows port of busybox if you want something more stable. w64devkit uses it.

https://github.com/rmyorston/busybox-w32

NetMageSCW5• 2 months ago

Not similar at all - too heavy weight when you just want to use a small tool.

chasil7• 2 months ago

This one might interest you, although it's quite old.

https://unxutils.sourceforge.net/

Busybox's shell is ash, but the above set includes an old zsh IIRC.

Note also that the Frippery Windows busybox is available as a 64-bit version, in case 2gb is not enough (easy with some big awk associative arrays).

d3Xt3r3• 2 months ago

How the heck is a portable 637KB .exe that doesn't require any installation, extraction or admin rights to run, "too heavy weight"?

asveikau• 2 months ago

I just have msys on my PATH.

hs86• 2 months ago

Would it make sense to add a prefix to all commands to avoid conflicts with built-in commands? Like how, on macOS and FreeBSD, installing GNU Coreutils adds a `g` prefix, Microsoft could add an `m` prefix to these commands.

jakegmaths• 2 months ago

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 connecting with WSL, and now you've got two file systems. WSL1 was in many ways better than WSL2 for these reasons.

aniceperson2• 2 months ago

the two filesystems can be a super power... i seamlessly use the same driver between wsl2 and my dual booted opensuse.

thewebguyd6• 2 months ago

Yeah I don't mind/like the two file systems. Looks like MS is taking it further too they also announced WSL Containers & API.

weregiraffe• 2 months ago

Windows really needs to ditch CRLF...

Windows needs to ditch itself.

saidnooneever• 2 months ago

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 consistent system to do things with dont pick a system which tries to be two systems.

Linux has wine. Windows has WSL.

I'd recommend BSD. any flavor will do.

might take some adjustments but you will have a more 'rational' system if that is what you desire.

(otherwise, embrace the madness!)

thewebguyd6• 2 months ago

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.

cardboard9926• 2 months ago

Don't think this will ever happen, especially since this is Microsoft you are talking about [0]

[0] https://www.youtube.com/watch?v=bC6tngl0PTI

rfgplk3• 2 months ago

Or better yet, just switch everything to full POSIX.

Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level). Windows technically provides some of them (or semantic equivalents) so you could make something work, but in order to do a full port you'd need to strip out too many concepts for it to be worthwhile. For instance the idea that "everything is a file" or the single root filesystem layout (which iirc is segmented deeply at the kernel level).

hnlmorg2• 2 months ago

Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level).

The kernels undoubtedly take different approaches. But there's nothing in NT that strictly prohibits POSIX compatibility layers. As we see with the many compatibility layers that have existed for Windows over the years.

For instance the idea that "everything is a file"

POSIX doesn't have a concept of "everything is a file". That's Plan 9. UNIX and POSIX actually made numerous concessions here and there are plenty of constructs that are not exposed as a file.

Windows does already abstract a few primitives as files too. In fact even DOS has the concept of device files, though in typical Microsoft fashion, it's implementation was a clusterfuck that took MS 40 years to fix.

or the single root filesystem layout (which iirc is segmented deeply at the kernel level).

NT uses an object system for filesystem objects, but it still has a root. As you can see in the WinObj (eg screenshot below)

https://learn.microsoft.com/en-us/sysinternals/downloads/med...

The C:\ convention is really more there for compatibility with DOS-lineage software but the underlying filesystem APIs work fine with NT objects.

For example, C:\foo.txt might be equivalent to \Device\HarddiskVolume3\foo.txt

In this regard, it's similar to how POSIX has a database of inodes and the filesystem hierarchy is actually just an abstraction that sits on top of that

Grom_PE• 2 months ago

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.

wnevets2• 2 months ago

I've mostly avoided CRLF by configuring text editors and git to use LF,

That has been my experience as well. I can't remember the last time I had an issue related to CRLF.

layer85• 2 months ago

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.

EvanAnderson5• 2 months ago

... Or better yet, just switch everything to full POSIX.

Interix[0] did a pretty good job of this, but MSFT killed it. I was compiling GNU tools w/ GCC and running bash under Interix back in in 2000 under Windows 2000. It was grand.

[0] https://en.wikipedia.org/wiki/Interix

dekhn2• 2 months ago

I ported a million-line, OpenGL/Motif application using Interix (before it was acquired). Indeed, it was grand.

pjmlp15• 2 months ago

The experience with Windows Services for UNIX wasn't that great, so yet another good product killed via acquisitions?

I only know it post acquisition.

avidphantasm5• 2 months ago

No, they need to ditch drive letters first. The NT kernel and NTFS don't even require them (I used to mount disks without drive letters back in the NT 4 era). They just don't care enough to get rid of this annoyance.

noselasd• 2 months ago

users , especially non-technical, find it highly useful in my experience. Is it a net positive to get rid of them, or will it largely only make developers happier ?

Dwedit5• 2 months ago

Nobody wants to use \??\GLOBALROOT\Device\HarddiskVolume3\ in their paths.

pjmlp15• 2 months ago

No worries, eventually Xenix will make a comeback.

You cannot ditch CRLF, Microsoft isn't Apple.

Windows accepts backslashes and forward slashes, only old applications that manually search for one of them get it wrong.

fg1372• 2 months ago

They might as well create a new OS with a different name, because none of the existing applications will work, and no enterprise customer will use it.

chasil7• 2 months ago

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

Dwedit5• 2 months ago

UTF-16 is also used by C#, Java, and JavaScript. Since JavaScript is so widely adopted, I wouldn't call it a rare bird. Not necessarily used when reading or writing files, but it's what's used internally for the strings. As a result, your strings use UTF-16 surrogate pairs to represent characters outside of the basic multilingual plane (such as Emoji).

zahllos2• 2 months ago

Additional Detail: it is specifically utf-16 little endian when a byte order mark is not used, which is the opposite of the recommended choice of big endian in the RFC.

Worse are the byte order marks required to support both endians that end up in files.

wvenable• 2 months ago

Windows is also a rare bird in UTF-16.

Web browsers use UTF-16 internally. So Windows isn't even largest "platform" that uses UTF-16.

0x1d76• 2 months ago

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

bvanheu• 2 months ago

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.

electroly• 2 months ago

UTF-16 is the internal format of the ICU library (International Components for Unicode, the support library from the Unicode standards people) which is a common way to add "full fat" Unicode support to a programming language. This has knock-on effects everywhere. If you're using ICU, you either use UTF-16, too, or you constantly convert back and forth every time you interact with ICU. You're often best off using UTF-16 in memory and only converting to UTF-8 when you write files or transmit over the network.

0cf8612b2e1e• 2 months ago

Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.

badc0ffee• 2 months ago

At which layer? dir /w, for example, is never going to list the contents of \w.

forrestthewoods3• 2 months ago

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.

yjftsjthsd-h6• 2 months ago

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.

Night_Thastus• 2 months ago

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

hnlmorg2• 2 months ago

break countless thousands of pieces of software

I'd estimate millions

sometimelurker• 2 months ago

maybe windows should actually just become linux

alok-g• 2 months ago

> Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes.

{To the extent such stuff is pragmatic:} I think we should switch to Pascal-style strings everywhere, and then have no need for having special-purpose characters like path separators (a path now being a list of strings).

pjmlp15• 2 months ago

Windows has been doing for quite a while, that is how COM strings work.

p-t• 2 months ago

Is this only on windows 11 or does it support 10 as well? (i cant access the site rn because of wifi)

Someone1234• 2 months ago

Windows 10 is end-of-life; so the question itself is odd. It may work on Windows 10, but they definitely don't support an EoL version of their OS.

Longhanks• 2 months ago

The question is not odd at all. Windows 10 Enterprise LTSC 2019 is supported until 2029: https://learn.microsoft.com/en-us/lifecycle/products/windows...

Also, MS does absolutely support EoL versions of their OS - it took MSVC's STL until 2024 to finally drop support for Windows 7 (whose final ESU update was 2023): https://github.com/microsoft/STL/issues/4858 - it isn't unlikely that they (STL maintainers) are not going to get approval for dropping Windows 10 support before 2029.

lhecker9• 2 months ago

It should work on Windows 10. If you're using PowerShell, you do need to have v7.4 or later installed, however.

EvanAnderson5• 2 months ago

I would have liked to see head, tail, tr, uniq, and cut. I end up dragging over the old "gnuwin32" versions of those to a lot of Windows machines. Those are my go-to tools for quick-and-dirty log analysis.

I know I could use Powershell for those kinds of tasks, and I certainly do make a lot of use of Powershell, but the familiarity of those simple tools and the decades-old "muscle memory" of using them on various Unix, Linux, and Windows boxes makes them hard to ditch.

ex1fm3ta2• 2 months ago

I use those commands also to filter output and fee ai agents with that. Tail and Head are my favourites to avoid wasting tokens. Wayy too many fancy build logs messages.

NetMageSCW5• 2 months ago

Windows has lacked decent ports of recent GNU tools for a while. I still use some very old ones. It would be great if MS worked on the other tool groups like textutils.

lhecker9• 2 months ago

I would have liked to see head, tail, tr, uniq, and cut.

The project includes all of those. Or were you talking about the past?

EvanAnderson5• 2 months ago

I'm a gigantic idiot who can't read. I was reading the table shell conflicts as all the included commands, and not just as a subset of commands that had shell conflicts.

A gigantic idiot. Sorry.

ilyagr• 2 months ago

Now the readme says

"Note: Any command not mentioned is included in this suite. "

which I found quite confusing. It's a very large set, potentially infinite depending on what the universe of all commands is :)

You should link to the list of all the commands in your package.

rfgplk3• 2 months ago

Isn't this just a restricted uutils fork? With most functionality culled for no good reason? "uname isn't useful on Windows" how? OSName/ Build numbers / systeminfo all exist?

natas2• 2 months ago

No thanks, I'd rather use linux.

fdefilippo• 2 months ago

https://frippery.org/busybox/

winget install -e --id frippery.busybox-w32

chasil7• 2 months ago

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

thedumbname• 2 months ago

Microsoft provides an awesome problem-solving solution, and 0 of the 6 problems they listed in the 'Windows caveats' section are solved.

EvanAnderson5• 2 months ago

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: Eschew "find.exe" on Windows for "findstr.exe". The latter is vastly more efficient. I discovered that by happenstance once and have trained my hands to type "findstr" when I mean "find" on Windows.

lhecker9• 2 months ago

We actually open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics. The installer allows you to pick what variant to use by default if the invocation is ambiguous.

capitol_• 2 months ago

Why not use ripgrep?

EvanAnderson5• 2 months ago

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.

RachelF• 2 months ago

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.

dizhn2• 2 months ago

Is 'dir' a Linux command?

wild_pointer• 2 months ago

It's a GNU Coreutils command.

https://www.gnu.org/software/coreutils/manual/html_node/dir-...

dizhn2• 2 months ago

I thought it was just a distro added alias like how some systems used to have '..' for 'cd ..'

adzm• 2 months ago

Finally, tee in the command prompt. I want to like powershell but the way it handles [] in filenames has bitten me so many times and fixing it turns simple things into verbose LiteralPath incantations

xnx• 2 months ago

Cool. I'm already using cygwin for a lot of these utilities. Would the Microsoft versions have any advantages?

chasil7• 2 months ago

No .DLLs would be the primary reason.

doctorpangloss• 2 months ago

Busybox for Windows is the best implementation of coreutils for it, far and away. The maintainer is also very knowledgeable and responsive and actually merges community PRs which is incredible. Microsoft isn't going to do that, so why bother? Microsoft's solution will be a hot buggy mess that needs its own workaround and quirks day 1.

mx7zysuj4xew2• 2 months ago

BusyBox IS NOT COREUTILS. ITS NOT EVEN REMOTELY THE SQME THING. It's something entirely different and not even remotely an adequate replacement

ilotoki0804• 2 months ago

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

spider-mario• 2 months ago

Or MSYS2, to go even further. https://www.msys2.org/

pipes3• 2 months ago

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

Thoreandan• 2 months ago

Close, it's MinGW/msys - different pathname semantics and under-the-hood approaches.

rzzzt3• 2 months ago

Cygwin executables need cygwin1.dll to run while MSYS-based distributions are using Windows APIs directly. One major difference is around process management: in Cygwin fork() is implemented* while MSYS2 packages will need to use whatever the NT kernel provides (i.e. also need to modify the source to build for this target): https://stackoverflow.com/questions/985281/what-is-the-close...

okanat10• 2 months ago

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

shevy-java• 2 months ago

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.

spidercat• 2 months ago

What does this do that Cygwin doesn't?

stronglikedan• 2 months ago

this conflicts with native shell utilities of the same name - take that, cygwin!

okanat10• 2 months ago

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.

signal11• 2 months ago

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.

0x1d76• 2 months ago

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.

yjftsjthsd-h6• 2 months ago

Surely WSL1 proves that it mostly can

okanat10• 2 months ago

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.

egorfine4• 2 months ago

Yeah, we don't hate this uutils (NOT coreutils) project enough.

mx7zysuj4xew2• 2 months ago

Not sure of it's sarcasm, but you'd be right, everyone involved with this garbage should be banned from IT forever

egorfine4• 2 months ago

It's not sarcasm. I truly believe that uutils exist solely for virtue signaling purposes and for better license for corporate (Canonical).

Dwedit5• 2 months ago

Will we ever see a Windows-optimized version of unix utilities that avoids creating new processes? It seems like that's the step that's really slow, and if you could reuse a process to continue running more commands, that would speed things up a lot.

okanat10• 2 months ago

Did you mean: Powershell or nushell

dekhn2• 2 months ago

Linux: first they laugh at you, then it embraces, extends, and extuinguishes Windows.

omoikane• 2 months ago

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

lhecker9• 2 months ago

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

natas2• 2 months ago

100% vibe coded.

compiler-devel• 2 months ago

tonymet• 2 months ago

FWIW, most of the powershell builtins are aliases for weaker methods like grep / select-string or cat for Get-Content. So you could likely install this without breaking anything.

I didn’t see less or a decent pager. MS needs their analytics on WSL and implement the top 50 commands on powershell

Powershell is very good, but lacks brevity and convenience of coreutils so this should be a big win.

yyyk2• 2 months ago

WSL1 is generally better for these usecases.

lousken• 2 months ago

ReFS -> ZFS

Remove batch, VBS and switch from powershell 5 to 7, add bash

Replace DSC in favour of Ansible

Remove windows registries

Switch to systemd for services

Rename folders like Users to home, programdata to etc, program files to opt, store/winget apps /usr

and call it microsoft linux server hybrid

Voultapher• 2 months ago

It's not seamless now is it if half the commands don't work.

Wine and other compatibility layers show that non-trivial software doesn't work if even one of the many layers uses something unsupported.

Jotalea• 2 months ago

what's the difference between these and the ones distributed in git for windows?

Coreutils for Windows

Related Stories