HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
uutils
coreutils
Rust2013–2026
uutils / coreutils

coreutils

Cross-platform Rust rewrite of the GNU coreutils

138Distinct people
162Mentions
1Explicit recommenders
24.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Cross-platform Rust rewrite of the GNU coreutils

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Link to the actual implementation: https://github.com/uutils/coreutils I love these re-implementations of things. Technology advances by the continued reinvention of the wheel,…

enriquto used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year162 dated mentions

Observed mentions: 2013-11-29 22:30:28 UTC to 2026-10-04 10:18:24 UTC.

01020302013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 17 mentions; 1 submissions, 16 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 23 mentions; 6 submissions, 17 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 28 mentions; 4 submissions, 24 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 26 mentions; 5 submissions, 21 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC110
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC615
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC707
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC817
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12012
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC17116
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC23617
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1019
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC918
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC1019
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC28424
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC26521

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
uutils coreutils uutils coreutils is a cross-platform reimplementation of the GNU coreutils in Rust. While all programs have been implemented, some options might be missing or different behavior might be experienced. We provide prebuilt binaries, manpages, and shell completions from main branch at https://github.com/uutils/coreutils/releases/tag/latest-commit . The latest stable tag https://github.com/uutils/coreutils/releases/latest also exists for reproducible products and packagers. Bug reporters should use binary from latest commit. Minimal compatible glibc version is same with ubuntu-latest runner. Use coreutils-*-musl if coreutils-*-gnu is not compatible with your system. Goals uutils coreutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs. Our key objectives include: Matching GNU's output (stdout and error code) exactly Better error messages: at a terminal, a parse error is shown as a compiler-style report with a caret under the argument at fault, where GNU prints a single line (see error diagnostics); scripts and pipes still get the plain GNU message Providing comprehensive internationalization support (UTF-8) Continuously improving performance; significant slowdowns relative to other coreutils implementations are treated as bugs Extensions when relevant (example: --progress) uutils aims to work on as many platforms as possible, to be able to use the same utils on Linux, macOS, *BSD, Windows, WASI and other platforms. This ensures, for example, that scripts can be easily transferred between platforms. uutils coreutils ships by default on Ubuntu since version 25.10. Documentation uutils has both user and developer documentation available: User Manual Developer Documentation Both can also be generated locally, the instructions for that can be found in the coreutils docs repository. Use weblate/rust-coreutils to translate the Rust coreutils into your language. You can try the utilities in your browser through the WebAssembly playground, without installing anything. Requirements Rust (cargo, rustc) GNU Make (optional) Rust Version uutils follows Rust's release channels and is tested against stable, beta and nightly. Building There are currently two methods to build the uutils binaries: either Cargo or GNU Make. Building the full package, including all documentation, requires both Cargo and GNU Make on a Unix platform. For either method, we first need to fetch the repository: git clone https://github.com/uutils/coreutils cd coreutils Cargo Building uutils using Cargo is easy because the process is the same as for every other Rust program: cargo build --release Replace --release with --profile=release-small to optimize binary size. This command builds the most portable common core set of uutils into a multicall (BusyBox-type) binary, named 'coreutils', on most Rust-supported platforms. Additional platform-specific uutils are often available. Building these expanded sets of uutils for a platform (on that platform) is as simple as specifying it as a feature: cargo build --release --features windows # or ... cargo build --release --features unix # or ... cargo build --release --target wasm32-wasip1 --no-default-features --features feat_wasm To build SELinux-specific features, including chcon and runcon, ensure that libselinux and libclang are installed on your system. Then, run the following command: cargo build --release --features unix,feat_selinux To speed up the checksum utilities (md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, and cksum) by using OpenSSL's libcrypto instead of the pure-Rust digest crates, enable the openssl feature: cargo build --release --features openssl By default OpenSSL is built from source and statically linked into the binary, so no runtime dependency on system libcrypto/libssl is added. To link dynamically against the system libcrypto instead, set OPENSSL_NO_VENDOR=1 at build time. MinGW (Windows) needs OPENSSL_STATIC=0 too for dynamic linkage. The speedup is largest on CPUs without SHA-NI hardware acceleration. aws-lc backend is used on MSVC. Setting AWS_LC_SYS_NO_JITTER_ENTROPY=1 at build time is recommended to reduce size of binary. If you don't want to build every utility available on your platform into the final binary, you can also specify which ones you want to build manually. For example: cargo build --features "base32 cat echo rm" --no-default-features If you want to build the utilities as individual binaries, that is also possible: cargo build --release --bins --workspace --exclude coreutils --exclude uu_runcon --exclude uu_chcon Each utility is contained in its own package within the main repository, named "uu_UTILNAME". To build selected individual utilities, use the --package [aka -p] option. For example: cargo build -p uu_base32 -p uu_cat -p uu_echo -p uu_rm GNU Make Building using make is a simple process as well. To simply build all available utilities (with debug profile): make In release mode: make PROFILE=release To build all but a few of the available utilities: make SKIP_UTILS='UTILITY_1 UTILITY_2' To build only a few of the available utilities: make UTILS='UTILITY_1 UTILITY_2' Installation Install with Cargo Likewise, installing can simply be done using: cargo install --path . --locked This command will install uutils into Cargo's bin folder (e.g. $HOME/.cargo/bin). This does not install files necessary for shell completion or manpages. For manpages or shell completion to work, use GNU Make or see Manually install shell completions/Manually install manpages. Install with GNU Make To install all available utilities (PROFILE=release by default): make install To install using sudo switch -E must be used: sudo -E make install To install all but a few of the available utilities: make SKIP_UTILS='UTILITY_1 UTILITY_2' install To install only a few of the available utilities: make UTILS='UTILITY_1 UTILITY_2' install To install every program with a prefix (e.g. u
Read the full README on GitHub

What Hacker News says

28 sources
> There will never be a slow and careful rewrite in Rust. Nobody wants to do it Lots of people want to do it. Whether you want to run any of their code is an open question - but rewriting old things from scratch is a very popular passtime. In fact, people are already doing it. For example, the recent sudo-rs rewrite. Or the uutils coreutils package: https://github.com/uutils/coreutils - Which passes almost all conformance tests now by the way. (Though they could certainly use a few more tests): https://uutils.github.io/coreutils/docs/test_coverage.html > doing it without introducing new bugs and security issues (not linked to memory) is even more difficult. Difficult, but not impossible. Plenty of alternate C compilers exist. And alternate SQL databases. And some web browsers. And email servers. And TLS implementations. And on and on. Arg
Read the rest
uably there already are several reimplementations of the "linux userland", with various tweaks. They're just called Freebsd. And Illumos. And MacOS. Why would the linux userland be uniquely impossible to reimplement in another language? I feel like people celebrate when someone makes a new text editor or gameboy emulator. Why so much hate at the idea of more implementations of unix tools?
In Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C
Not sure if I (as an unsuspecting Ubuntu user) am really ok with this. I'm not saying they should wait until version 1.0 (currently uutils/coreutils is at 0.2.2), but at least until the green line reaches the blue line in this graph: https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-t... Of course, "exotic" bugs might happen (not sure how exotic the bug that caused this issue was), but can a software really be considered production-ready if it still fails part of the testsuite of the software it should replace? I don't think so... If you look at "date" specifically on https://uutils.github.io/coreutils/docs/test_coverage.html, it looks much worse than the overall graph suggests: 2 tests passing, 3 tests skipped, 3 with errors. Not really reassuring, right?
In Date bug in Rust-based coreutils affects Ubuntu 25.10 automatic updates
yeah, based on some more digging, it looks like a test case for `date --reference` in GNU coreutils was only added a few hours ago [0] so I assume it was in response to this bug. but I don't think that should let the uutils authors off the hook - if `--reference` wasn't implemented, that should have been an error rather than silently doing the wrong thing. after even more Git spelunking, it looks like that problem goes all the way back to the initial "Partial implemantion of date" [1] commit from 2017 - it included support for `--reference` in the argument parsing, including the correct help text, but didn't do anything with it, not even a "TODO: Handle this option" comment like `--set` has. 0: https://github.com/coreutils/coreutils/commit/14d24f7a530f58... 1: https://github.com/uutils/coreutils/commit/41d1dfaf440eabba3...
In Date bug in Rust-based coreutils affects Ubuntu 25.10 automatic updates
annoyingly, they don't link to the actual bug in question, just say: > Systems with the rust-coreutils package version 0.2.2-0ubuntu2 or earlier have the bug, it is fixed in 0.2.2-0ubuntu2.1 or later. based on the changelog [0] it seems to be: > date: use reference file (LP: #2127970) from there: [1] > This is fixed upstream in 88a7fa7adfa048dabdffc99451d7aba1d9e6a9b6 which in turn leads to [2, 3] > Display the date and time of the last modification of file, instead of the current date and time. this is not the type of bug I was expecting, I assumed it would be something related to a subtle timezone edge case or whatever. instead, `date -r` is supposed to print the modtime of a given file: > date --utc -Is -r ~/.ssh/id_ed25519.pub 2025-04-29T19:25:01+00:00 > date --utc -Is 2025-10-23T21:46:47+00:00 and it seems like the R
Read the rest
ust version just...silently ignored that expected behavior? maybe I'm missing something? if not this seems really sloppy and not at all what I'd expect from a project aiming to replace coreutils with "safer" versions. 0: https://launchpad.net/ubuntu/questing/+source/rust-coreutils... 1: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu... 2: https://github.com/uutils/coreutils/issues/8621 3: https://github.com/uutils/coreutils/pull/8630
In Date bug in Rust-based coreutils affects Ubuntu 25.10 automatic updates
> when people talk about safety, it does matter in Rust, right? I'm not sure I would make this about languages. Different languages have different advantages, but there's always a trade-off, right? For example, this `cp` issue is a bit of a problem for the coreutils rewrite[0]. I think you gotta ask the question: what benefit does rewriting in rust provide? Potentially more safety, but also something like coreutils has been heavily investigated for the past few decades. Rewriting also comes with the chance of introducing new bugs. So is it safer? Hard to say, right? Especially since Rust is still new and there's not a lot of major software written in it. > Everyone says 1k LOC is nothing > Or what is your point? The point we're trying to make is that lines of code are not the bottleneck. Probably one of the big problems with our ind
Read the rest
ustry right now is an over reliance on metrics (KPIs). But what can you measure in coding? Lines? Commits? Tickets? Is any of that meaningful? I said in another comment[1] that I've spent hours or days to write /one line/ of code, or even partial. Does that mean I was doing a bad job? Was I just slacking off? I think this is something many developers have experienced. Were we all lazy? Dumb? I'd argue that you can't answer that question from the information alone. Sometimes a single line of code is crazy hard to figure out. If you haven't seen this before, allow me to introduce you to some old coding lore[2] //When I wrote this, only God and I understood what I was doing //Now, God only knows The thread has other examples of where people have wasted time trying to understand some "magic". Or maybe you know Carmack's Fast Inverse Square Root Algo[3]. Look at that one. It's 7 LOC (5?) yet those lines are so powerful. That is not the type of code someone writes in a flow state, off the top of their head. That is the type of code you write because you used a profiler[4], found the bottleneck, and optimized the crap out of it. Writing 7 lines takes no time, but I'm sure that code took at least a week to write. The point here is that it is really hard to measure the quality and effectiveness of a programmer. The context of the problem is not something that can be abstracted away when evaluating them. Unfortunately, this means to evaluate them you also need to be an expert programmer AND have meaningful context to understand the specific problems they are working on. There's not a thing you can do from a spreadsheet. The truth is that if you optimize from the spreadsheet you'll only introduce more Jira tickets. There's a joke that there's 2 types of 10x programmers. The other one is the programmer that introduces 100x the jira tickets while completing them 10x as fast. The problem is that that programmer doesn't see the bigger scope and makes mistakes that leads to new tickets. This might be like your new rockstar junior dev. They fill out tickets but are solving the problems in isolation, not in context of the codebase. This leads to more complexity and bugs later on, but that lag in effect is hard to measure/identify so it is easy to think they are a rockstar but actually a problem. > I start small, I can review just fine. Yes, and this is how you should do it. I mentioned Unix Philosophy[5] previously. But the thing is that projects continue. Scope expands. If you want to keep writing small programs and integrate them together then you actually need to think quite carefully about the design and implementation of them (again, see Unix Philosophy). So the point is that everything is highly context driven. That's what matters. You need nuance and care. It is not easy to say what makes good code or even identify it. So... LGTM [0] https://github.com/uutils/coreutils/issues/7092 [1] https://news.ycombinator.com/item?id=45409430 [2] https://stackoverflow.com/questions/184618/what-is-the-best-... [3] https://betterexplained.com/articles/understanding-quakes-fa... [4] https://news.ycombinator.com/item?id=45060059 https://news.ycombinator.com/item?id=44416817 https://news.ycombinator.com/item?id=45060059 [5] https://en.wikipedia.org/wiki/Unix_philosophy
In The AI coding trap
hopefully they got reported as bugs, I spent some time in June making sure a basic Arch Linux system can compile itself using uutils, and things mostly worked, the only build failures could be argued were shell scripts depending on undefined behavior, like "calling install(1) with multiple -m arguments": https://github.com/uutils/coreutils/issues/8033 The other one was an edge-case with dangling symlinks: https://github.com/uutils/coreutils/issues/8044 Both got fixed promptly, after taking the time to report them properly. :)
In Ubuntu 25.10's Rust Coreutils Is Causing Major Breakage for Some Executables

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.