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

17 sources
A bunch of different things, few of which I got actual traction on, in true ADHD form (though some of that was being unable to go to the local hackerspace, for hardware work) One thing which has been rather fun and successful, is speeding up uutils' implementation of integer factorisation: https://github.com/uutils/coreutils/pulls?q=is%3Apr+author%3... (uutils is a Rust reimplementation of the GNU coreutils and findutils) I'm not yet satisfied with the performance, and I still have quite a few ideas how to improve it, but it's still more than 44 times faster than it was when I started (measured on factoring everything between 2 and 10⁷; it's a lot more on larger / more-interesting sizes)
In Ask HN: What did you make during lockdown?
The first four utils were added 7+ years ago: https://github.com/uutils/coreutils/commit/9653ed81a2fbf393f... This has been developed for a while. You're looking at the official GitHub releases which doesn't mean much. It just means they just started providing official compiled releases. Not all projects even do that at all. I know a lot of people getting into Rust, including myself, started reading through this repo. This was one of the first good real-world examples of Rust, that I found.
In Re: Integrating "safe" languages into OpenBSD? (2017)
> Or is there something I'm missing here? There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downloaded. One thing that may be skewing the count is that internally coreutils is packaged with one crate per command. There are about 100 commands, so you'll have seen at least that many separate crates building. They're listed here: https://github.com/uutils/coreutils/blob/6e8c901204934029c88... My impression is that ecosystems where tracking dependencies is hard tend to discourage them, while ecosystems where tracking dependencies is easy encourage them. The coreutils crate depends on separate md5, sha1, sha2, and sha3 crates, if managing external dependencies was hard I imagine those would be bundled together. But it is easy, so it makes sense to organise the crates so that each jus
Read the rest
t provides one specific piece of functionality. Think single responsibility principle applied to packaging.
In Re: Integrating "safe" languages into OpenBSD? (2017)
BSD does not use GNU coreutils. Is it really unexpected that the developer of a BSD project might have been unaware at the time of a project attempting to replace it, or simply found it incompatible with the stated requirements-- POSIX compliant base utilities. OpenBSD does not care about compatibility with GNU, for example longopts do not work for many utilities, with exceptions to permissive replacements to historically used GNU utilities (grep example). It also does not address the concerns of higher build times compared the contemporary C counterparts, which also support far more platforms than Rust. The use of cargo for example suggests that at least a few uu utilities makes network connections at build time to fetch dependencies! For example something as simple as chown: https://github.com/uutils/coreutils/blob/master/src/uu/chown..
Read the rest
In Re: Integrating "safe" languages into OpenBSD? (2017)
> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust (https://github.com/uutils/coreutils). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic. Especially considering that the gate in question has already been thoroughly breached by the language in question (some universities have switched to using Rust in their OS courses, for example).
In Re: Integrating "safe" languages into OpenBSD? (2017)
A rewrite of core utils[1] was started in 2013. commit d4e96b33e343733992fad55ac840c9649cd72ede Author: Jordi Boggiano <j.boggiano@seld.be> Date: Fri Aug 2 09:22:57 2013 -0700 Initial commit Although I hope that Redox[2] takes off more so than rust makes it into existing systems. I dream of one day ordering a System76 with Redox already installed. [1]: https://github.com/uutils/coreutils.git [2]: https://www.redox-os.org/
In Re: Integrating "safe" languages into OpenBSD? (2017)

Showing the 15 most recent of 17 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.