The Rust Implementation of GNU Coreutils Is Becoming Remarkably Robust

https://www.phoronix.com/news/Rust-Coreutils-uutils-2023

by sdht0 • 3 years ago

261 218 3 years ago

I just wish it was copyleft like the real coreutils instead of being pushover-licensed. Now the corporations are all going to start making proprietary forks of this.

mouse_• 3 years ago

pushover-licensed

Huh, never heard the polite form of that term.

INTPenis• 3 years ago

What's the opposite of a pushover-license? A bully-license? ;)

bschwindHN• 3 years ago

In practice, what are the worst case scenarios for a corporation making a fork of the "mv" or other commands?

chomp• 3 years ago

In practice, there's no disaster scenario. The issue is the potential for leaving effort and hard work on the table, because a company could improve upon your code and never release it.

For example, we have Rocky and Alma Linux because so much of RedHat is based on GPL-licensed GNU/Linux. They technically don't have to release any of the MIT components, they do it because they are nice stewards of open source. Same with Ubuntu. And SUSE. Other companies could be not so nice. For instance, note that Google Chrome is not technically open source. Only Chromium is, which Chrome is built from.

In reality, MIT binaries without the source code are rare.

jacooper2• 3 years ago

And feature creep for each jloud providers distro starts happening, till they are now totallt different behaviors and features for each provider.

m4rtink• 3 years ago

You mean like most Android user-space right now ? And its billion proprietary forks by Android vendors.

snvzz3• 3 years ago

It's their project, and they're free to use whatever license they want.

MIT is a good choice for maximizing adoption, which possibly is their intent.

Now the corporations are all going to start making proprietary forks of this.

I have a hard time coming up with a scenario where a company would do this. There's literally nothing to gain from doing so.

riffraff7• 3 years ago

There's literally nothing to gain from doing so.

And yet KHTML was forked into WebKit which was forked into Blink, just to name one.

OSX has forked BSD code, as did windows.

This things happen all the time. MIT is a fine license, so is GPL, but we can't just say "oh nobody is going to fork this, it's dumb!" because it happens all the time.

dhosek• 3 years ago

There’s nothing more annoying than GPL absolutists. Who really cares if someone makes a closed-source fork of the code? On the other hand, given that closed-source code is going to exist, isn’t it better if it’s able to use the best code available rather than forcing developers to either ignore the existence of something because it’s GPL’d or just ignore the license in the first place?

There’s a reason I choose MIT over GPL. It’s a freer license.

alwayslikethis3• 3 years ago

GPL protects the software itself against becoming proprietary. Developers are forced to ignore GPL'd code only if they are unwilling to distribute their code under GPL, because the company is unwilling to make a pledge to respect the freedom of the users. Writing more GPL'd code gives advantage to those who are willing to respect the user's freedom.

pjmlp9• 3 years ago

That is why FreeBSD is everywhere, with nice contributions from all its commercial users, and clang is ISO C++20 compliant thanks to all those nice compiler vendors thinking of upstream.

fractalb3• 3 years ago

Who really cares if someone makes a closed-source fork of the code?

Weren't Amazon and ElasticSearch on news a few years back about some license changes?

chrismsimpson2• 3 years ago

Every bit this. How about the freedom to ship something without having an ideological position on when/how it links against other code.

forty2• 3 years ago

Consider the Linux kernel. First it would probably have never been successful with a liberal license in the first place, but let's ignore that for a second and assume it got successful anyway.

If you look at the current situation where each SoC supports only one (generally very old and very vulnerable) kernel, I think we have an the reasons to be happy that they at least have to release the sources so hopefully someone can extract the patch and have it work on recent kernel. It's not very hard to imagine the situation where we'd only have the binary kernels if we did not have the GPL.

xorcist• 3 years ago

"More" or "less" free is a word definition game that is mostly a chimera. It depends on what the purpose of the software is and which business model is the most fit.

Copyleft software has several vendors compete around the same product. Every economic actor has to compete to add business value and consulting, with the knowledge that any extension to the software is made available to everyone else.

Free and non-copyleft software leaves vendors free to compete with different products built from a common base. Extensions to the software has commercial value and every vendor seeks their local maxima.

So the situations are different. GPL and BSD software do not often compete in the same space, with a few exceptions. There used to be a commercial variants of BSD, but they are all gone, outcompeted by a common Linux platform. FreeBSD was technically superior for a long time but couldn't compete with a multi vendor product in the long run.

Products that represent a common platform shared by several products however are more successful non-copylefted. Formats such as gzip and jpeg are completely dominant due to their multi product usage, and any GPLd codecs that competed with them are mostly forgotten.

CobrastanJorji• 3 years ago

This always seemed like a terrible idea to me, from the corporation's perspective. Sure, great, you spent a few thousand dev hours and found a clever way to significantly improve the performance of your mallocs. Awesome, you saved 5% on your hardware costs. Good deal.

But now you've got a private fork to maintain. The guy who figured out the optimization was promoted and switched orgs, so the other guy on that team is in charge. There's not quite enough work for him to work on merging stuff in full time yet, so he'll do other stuff, but within a few years, keeping your private fork up to date with security patches is a full time job, then more than a full time job, and nobody wants to join that guy's effort because there's no glory and no promotions in it. But there's no getting off this ride anymore, and nobody's doing expensive performance testing anymore because the guy who knew how to do it is long gone, so I hope it's still making a difference. Ugh. Just share the fix.

regularfry• 3 years ago

Or a proprietary fork to not maintain, and now nobody else is doing it either. This works for getting a product out of the door so if your planning horizon is the next three months it looks like a great idea.

camgunz• 3 years ago

This makes sense from an engineering perspective, but misapprehends the purpose of most corporations, which is to funnel rent and laundered government money (subsidies, zero interest rates, contracts) into executive salaries and shareholder returns. This explains why most companies don't care about their products or the people who make them: they're perfunctory.

rurban2• 3 years ago

Maintaining private forks/patches is certainly not a full-time job with git rerere, it's rather trivial. I do maintain hundreds of forks/patches updated daily fully automatically, and I have to engage in manual fixups for maybe 10hrs a year.

The fixes/extensions are shared, but don't expect them to be looked at. On some projects some PR will take years. And some, like OpenSSL or coreutils outright refuse to add new features, or fix code quality.

alwayslikethis3• 3 years ago

That's the main thing I have against the Rust people. They seem to like pushover licenses instead of GPL, perhaps in the hopes of getting hired by one of the big tech corps at some point. If only they realized what made free software so resilient over years..

kzrdude• 3 years ago

Not sure it's fair to generalize over all "Rust people"

I've worked in the community and it's annoying that it's so against GPL in some corners, but most people are just pragmatic. They use whatever license is the norm for sharing with their community.

Now that Rust is becoming less tight knit it might open up, hopefully, to more diversity in licenses.

gpderetta• 3 years ago

I'm a big fan of copyleft licenses, but when the objective is to push the industry toward a better standard, as opposed to a specific implementation, permissive OSS licenses make sense.

pas3• 3 years ago

The intention behind GPL is great, but it's a technologist response to a social issue.

If we want a software commons we have to say that upfront, not try to imply it via legalese, and then get offended when fractions emerge.

jillesvangurp3• 3 years ago

I think that's mostly not a thing. The problem is largely imaginary. Most MIT/Apache/BSD/etc. licensed stuff isn't commonly forked by big corporations. Why would they? It's mostly not that practical to maintain private forks of software. And so what if they do?

These are still OSI endorsed licenses of course. So, bona-fide free and open source software as defined by the Open Source Initiative.

Referring to them as push over licenses is not really that constructive. All sorts of respectable OSS software is licensed with these licenses. I'd go even further and state that if you remove all the OSS software that doesn't have a copyleft license, the whole landscape would get a lot less interesting. That gets rid of most popular libraries, lots of popular software packages, all kinds of critical could infrastructure components, development tooling, etc.

The vast majority of OSS software I depend on is actually Apache 2.0 and MIT licensed. There's a fair bit of GPL v2 and MPL in my life as well. GPLv3 and AGPL are just much more of a fringe thing. I tend to actively avoid depending on any such software. Just too much hassle in terms of endless debates of what is and isn't allowed with such licenses and people getting upset if you actually try to use the software for something not endorsed by them. Mostly the venn diagram of such people and people producing useful things to me is pretty narrow anyway. I know legal departments in big corporations tend to have similar policies.

goodpoint5• 3 years ago

The problem is largely imaginary.

Ever heard of Android, cloud or SaaS? For example our phones and the cloud services they use are choke-full of FOSS, but we plenty of surveillance and very little freedom. Same for modern cars, TVs and many other things.

There are plenty of user-hostile services that use FOSS internally. Weak licenses are huge enablers for this behavior.

goodpoint5• 3 years ago

Same here. Reimplementing something with a weaker license is not a friendly behavior.

mustache_kimono5• 3 years ago

But reimplementing something with a "tougher" license is friendly? I think this is one of those "where you stand depends on where you sit" things.

jeff_carr• 3 years ago

I just wish it was copyleft

Yes, the GPL is very important. The BSD license _is_ a problem. Those of you that were around when FreeBSD was maybe going to 'win' remember why Linux(GPL) ended up capturing everyone's attention.

You can not count on your code staying free if it's under a BSD license. If there is a way to make money on it, someone will fork it privately and force you to pay for it. If they don't succeed, you will still be under continual threats that you will have to pay for it.

rocqua3• 3 years ago

Why did Linux end up capturing everyone's attention? I wasn't around back then.

mustache_kimono5• 3 years ago

FSF/GPL advocate: "I don't like that someone else is reimplementing this code."

Jesus, you think s/he ever wondered how AT&T felt about Linux and the BSDs literally reimplementing all of Unix?

Oh, that's right. This is the FSF/GPL conundrum -- you're likely to end up on both sides of every issue. You will literally be both a copyright maximalist re Linux and a copyright minimalist re proprietary code, music and film.

BirAdam• 3 years ago

Corporations use copyleft stuff all the time too. FOSS subsidizes mega corporations, which sucks. Thing is, it’s also a subsidy for all of us.

hulitu• 3 years ago

The Rust Implementation of GNU Coreutils Is Becoming Remarkably Robust

And performance ?

snvzz3• 3 years ago

There's some benchmarks in the talk.

It is significantly faster than coreutils in some situations.

They also know cases where it is slower, and thus I doubt it'll remain so.

KRAKRISMOTT• 3 years ago

Code is cleaner too, fewer hacks than typical Coreutils code. You get the benefits of BSD style clean code while still having high performance because there are clear functional boundaries and specific features are compartmentalized in modules and dependencies. Systems programming has finally caught up to 30 years of advances in software engineering.

Long live the Rust Evangelism Strike force. Finally Apache/Linux is now possible.

Gigachad• 3 years ago

I've seen that rust based tools seem to be significantly faster on average than their traditional C versions. Seems to be due to using newer algorithms that make use of modern CPU features.

AndrewDavis• 3 years ago

I'm now imagining a distro using relibc (rust implementation of POSIX libc from RedoxOS) and uutils.

rlpb2• 3 years ago

How does Rust work with dynamic linking? I thought it didn't?

aldonius• 3 years ago

Rust can dynamically link to/like a library written in C if you really want it to.

https://doc.rust-lang.org/nomicon/ffi.html

shaunsingh0207• 3 years ago

I currently build my nixOS packages with musl, clang, and uutils, and the difference from gcc/coreutils/glibc is unnoticeable. The uutils project is great

throwaway777845• 3 years ago

are they fully compatible?

d12bb2• 3 years ago

They're on their way: https://uutils.github.io/user/test_coverage.html

pjmlp9• 3 years ago

I remember previous attempts to do this in Ada.

stevekemp• 3 years ago

I remember in 1999 there was a project to reimplement a bunch of these tools in perl:

https://perlpowertools.com/

I even contributed a little, back then. I guess writing basic versions of "ls", for example, is trivial. But there's a lot of work getting all the tools done, with all the flags implemented and behaving as expected.

I guess there are tools like busybox, toybox, and similar, which also implement a lot of "stuff" to varying degrees of completion. From my side the biggest takeaway from those projects is the sheer convenience of deploying a single binary and installing symlinks to change functionality.

I replicated something similar with my sysbox project, collecting tools together in one golang binary with various subcommands:

https://github.com/skx/sysbox

I use at least one of those tools on a daily basis, though I suspect they're not so universally useful.

anthk• 3 years ago

Perl was already reimplementing sed/awk and sh in a weird C-ish way, so doing unix utilities would be a piece of cake in Perl.

timbit42• 3 years ago

I searched for 'implement coreutils ada' but nothing came up.

What happened?

0x008• 3 years ago

How do you measure robustness except with failures / years of service x times deployed ? You cannot make edge cases and strange unique behavior happen in a controlled environment.

yjftsjthsd-h4• 3 years ago

You cannot make edge cases and strange unique behavior happen in a controlled environment.

Sure you can. Go iterate through the GNU Coreutils bug tracker, find weird bugs, create test cases, feed them to your implementation. Bonus points if you can find an existing test suite (ex. xfstests turns out to be good for testing arbitrary filesystems). Granted, there will always be edge cases that you don't catch until they show up live in prod, but you can hit a chunk of the space without that.

retcond• 3 years ago

You have just contradicted yourself by saying,

there will always be edge cases that you don't catch until they show up live in in prod.."

in reply to,

"How do you measure robustness except with failures / years of service x times deployed ?"

The only viable live testing environment that springs to mind might be running your test code synchronously at the atomic level with production, which I'm convinced only IBM Z/OS on a Parallel Sysplex cluster running CICS can do.

Ed.spelling

kaba0• 3 years ago

Also, there are plenty of package system that uses coreutils for their build instructions. Just build the whole thing with coreutils aliased to the rust implementation and check for errors.

Cthulhu_2• 3 years ago

One tool that (I think?) wasn't around, wasn't used as much, or couldn't be deployed at scale back then was fuzzing tools; modern-day application of fuzzers on existing libraries and tools has revealed thousands of potential bugs.

If fuzzing, unit tests and things like mutation tests are written and automatically applied to these libraries/utils, on top of being written in a proven memory-safe language like Rust, I would assert they're pretty robust.

Second, there's more known knowns this time around; they can write test cases for the decades of bugs and rare occurrences found in the tools they replace.

That said, I'm sure there's still plenty of unknown unknowns that can only be uncovered with, as you said, years of service and times deployed.

dezgeg• 3 years ago

How well is this working nowadays with non-UTF8 input?

unixgoddess5• 3 years ago

I wonder why not reimplement coreutils as library functions, to be used within an ad-hoc REPL. It would be much more flexible and extensible.

AFAIK, originally the reason why they were made as programs was that the available programming languages were too cumbersome for such use. Now we have plenty of experience making lightweight scripting languages that are pleasant to use in a live environment (vs premade script), so why give up the flexibility of ad-hoc scripting?

cleanchit2• 3 years ago

Inertia

lelanthran3• 3 years ago

I wonder why not reimplement coreutils as library functions, to be used within an ad-hoc REPL. It would be much more flexible and extensible.

Doesn't busybox do something similar - (almost) everything is in a single binary.

unixgoddess5• 3 years ago

nope. it's still a traditional binary meant to be used as traditional binaries from the posix shell. What I mean is, replace both the binaries and the shell with a library equivalent of coreutils running from a REPL.

ahepp• 3 years ago

Isn't what you're describing basically a unix "shell" like bash, csh, zsh, etc?

I agree that something like bash leaves a lot to be desired in REPL functionality. Its ubiquity is convenient, however.

westurner• 3 years ago

BusyBox has Ash sh and a number of other binaries all compiled into a multiply-symlinked executable.

BusyBox and Ash (and Bash) in Rust would be neat. IDK that docstring parity would be a good thing?

There's also RustPython.

pdpi• 3 years ago

The goal here is to provide a safer implementation of the core tools you need for a Unix system. The nature of these things is set in stone.

You’re describing an interesting project, but it’s not _this_ project.

unixgoddess5• 3 years ago

what if it were written as a library, with the traditional cli implementation as a thin layer over it?

I'm thinking about the wider FOSS ecosystem, for example if Firefox was built as a gui gluing together a modular collection of libraries people could do all sort of cool things with them.

Monolithic applications make sense for proprietary software, not so much for FOSS.

matheusmoreira3• 3 years ago

The problem is POSIX. It says operating systems must have mv, cp and all that stuff. This is the reason why people say Linux is not an operating system.

I wonder why not reimplement coreutils as library functions, to be used within an ad-hoc REPL.

Funny you mention that. I've been working privately on such a "systems programming REPL" in my free time. Basically a freestanding Lisp with pointers and built-in Linux system calls. It's been a huge challenge trying to bootstrap and get the garbage collector working without any libc support, still haven't cracked it.

Languages like Python and Ruby already have system call capabilities. You can literally do anything with those calls. So this already exists in some form, albeit not in the extreme form I envisioned.

chrisjc2• 3 years ago

I've been working privately on such a "systems programming REPL" in my free time. Basically a freestanding Lisp with pointers and built-in Linux system calls.

Are you building something similar to babashka? Would you be able to figure out what they did with babashka to figure out what you've been unable to do, or are you challenging yourself?

https://github.com/babashka/babashka

theamk• 3 years ago

because most of the coreutil functionality is already availible in libraries of most languages. Article mentions that there are crates for the logic. The hard part is command line parsing and output formatting, and your library should have neither of those.

I've seen plenty of shell scripts rewritten in Python because they grew too big, and most of the time coreutil commands just get replaced with standard library calls. There are exceptions (like sorting files which do not fit in memory) but otherwise standard library is good enough

harry82• 3 years ago

How does this work wen you want to add a flag?

Eg once upon a time I thought it would be fun to add a flag to ls to limit its results to a certain kind of file so you could list only directories for example. It came up for me as something I needed so I did it. Somebody on the gnu mailing list for core utils rejected it on the basis of ls "having a high bar" for a new flag. $ man ls suggests this hasn't been a consistent policy. It wasn't clear to me if that person was in charge or it was just a vague notion of theirs or anything useful so obviously I dropped it because I'd have something different from someone if there was any interest.

The Rust implementation might come to precisely the same conclusion that it isn't worthwhile. But they also might not on some case if not that one.

Do they do what's better or do they do what's Gnu always and everywhere?

Do they wait until they have significant traction and only then consider such things?

Interesting questions for them to ponder and maybe they have?

terts6• 3 years ago

One of the maintainers of uutils here. We have a few flags that are not in GNU for one reason or another. Some were rejected by GNU, others come from other coreutils implementations like FreeBSD. We document those at https://uutils.github.io/user/extensions.html

We tend to do this sparingly, however, because even just adding new flags might break existing scripts that use abbreviated long options. For example, if the flag you propose is called `--filter` it might break scripts that use `--fi` as a shorthand for `--file-type`, because the prefix is now ambiguous.

I personally like the flag you propose!

pas3• 3 years ago

How about introducing three dahses for these custom parameters/flags?

Regarding filtering. In a busybox situation depending on some regex crate is a given anyway, but if we are talking about separate binaries adding it to `ls` makes it bigger for everyone, even for those who will never use this feature. Does piping the results to grep make things so much slower that adding filtering to ls is "worth it"? Is this pushing the "philosophy" of do one thing well and be compostable too much? How many kilobytes are we talking about anyway?

Care to share your opinion on these theoretical/pragmatic questions? Thanks!

ricardobeat2• 3 years ago

That's the first time I hear of this "feature" (using `--fi` instead of `--file`). I tried a few commands in my shell and none actually support it. How common is this?

mcqueenjordan• 3 years ago

Oh wow, I had no idea that was a feature. That significantly hampers extending the tools in the future. Has there ever been a discussion to consider breaking that functionality? (I understand it could be a huge impact & not worth it, but just curious to read the discussion if it exists.)

emmelaich• 3 years ago

FWIW, this particular behaviour can be achieved with `find . -type d -maxdepth 1 ....`

efreak• 3 years ago

A solution might be too only allow traditional flags to be shorthand, and require the full long option for new flags.

vbezhenar• 3 years ago

I wish someone would build modern lean utils. I don't need bazillion grep flags. There's so much unnecessary repetition in unix tools. Why make separate flag for input and output files when I can just redirect input and output with shell, just for one example. Theoretically most unix tools could be implemented in very few lines of code and that's their beauty.

glutamate• 3 years ago

grep implemented in a few lines of code would not be very fast: https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...

devnullbrain• 3 years ago

Theoretically most unix tools could be implemented in very few lines of code.

So do it?

tsimionescu12• 3 years ago

Theoretically most unix tools could be implemented in very few lines of code and that's their beauty.

As usual, theory and practice should be the same in theory, but they are different in practice.

It turns out that the Unix philosophy of gluing together programs by spitting out and re-parsing text is both extraordinarily brittle for automation purposes, and quite tedious for manual work.

So, to make realistic use of these tools, there's lots of flags to force the output to be as structured as possible for various automation tasks, to make parsing the output tractable (and to ask for explicit guarantees on the format).

Then, to achieve many common tasks without having to write your own parser and text manipulation in awk or whatever, you need many other flags for transformations which are trivial on the base data types but complex for formatted text, such as sorting files by a last modified (which is `ls -lt` with flags, and a terrible amount of work that I'm not going to go into using Unix pipes - at least if you want to support such complex things like file names including whitespace, or dates in the current locale).

vkaku• 3 years ago

This is great. Chimera Linux uses the FreeBSD userland version of the utilities. It's refreshing to see new distros taking charge of their development.

nishs3• 3 years ago

from the slides:

Lots of crates (Rust libraries) available - Don't have to reimplement the wheel:
lscolors, walkdir, tempfile, terminal_size

i believe this isn't always quite an advantage that the slides make it out to be when implementing tools as critical as coreutils. you typically would want internal packages that you can precisely control.

sophacles2• 3 years ago

Why?

SQueeeeeL• 3 years ago

Not the original poster, but coreutils are almost given similar design requirements as airplane software. They need to be fast and they need to be perfect. Having a dependency tree which invokes items that (potentially) don't place as much emphasis on being error free can lead to buggy software.

Remember, there is no reason for anyone to choose the rust implementation, other than philosophy. They need to match or surpass the C implementations with an extreme degree of consistency to be worth the risk of transferring.

raverbashing• 3 years ago

walkdir and tempfile should be simple enough for what they need to do and if it merits a change then that's totally worth taking upstream

Rust should definitely have a good "stdlib" or at least an extended base library to be used for stuff like this.

rocqua3• 3 years ago

Version pinning and manual verification of correct implementation can work quite well here.

nishs3• 3 years ago

wholeheartedly yes; this addresses nearly all the concerns i had in my comment.

the only other concern is the ability and the added time to make changes to these dependencies. what this sometimes means in practice:

in terms of time: you may have to wait for upstream to accept your change. alternatively, one could maintain a fork of the package and replace the dependency to point to the fork while waiting for changes to be accepted, however doing so adds back-and-forth work.

in terms of ability: upstream may reject a change.

after the change is merged upstream, you are required to vet commits in the dependency between the last previously vetted commit and your currently merged commit, all at once, before you can upgrade the dependency in your original project.

schemescape• 3 years ago

How many transitive dependencies result? And what licenses are those crates released under?

Edit: I feel like this is often overlooked, but most licenses require including a copy with binary distributions, and wrangling all those text files can be surprisingly cumbersome. Omitting a license can lead to headaches down the road.

synergy202• 3 years ago

the coreutil rust flavor is 16MB per its release build. after strip it cuts down to 10MB, that's the smallest size you can have.

Comparing to c version coreutils, which totals up to 5.8MB, rust does have a slight size "problem", its size is 70% larger even with the busybox-all-in-one style.

you're actually forced to do it the busybox style, otherwise each single small utility of coreutils will be about similar size, say, 6MB for each one, then it will just blow up really fast.

I commented somewhere else, the rust stdlib by default(AND by design) is statically linked, which is totally different from the shared stdlibs like C and C++ etc, that will leads to large size when you have a few of rust release binaries. I have never figured out why Rust can not do the shared-stdlib -just-like-c-c++ yet.

sgerenser• 3 years ago

Isn’t the problem Rust not having a stable ABI (at least that’s what I heard)? Unstable ABI doesn’t work well with dynamic linking.

synergy202• 3 years ago

is the 'unstable abi' by design too? or is it just still evolving? why can't Rust have a stable ABI like libc and libstdc++? this is the major reason I did not use Rust so far indeed, and I don't know Rust enough why it is the way it is as far as stdlib-static-link goes.

shrubble• 3 years ago

Robust in comparison to what? Is the current coreutils lacking in robustness?

doomrobo• 3 years ago

It had some CVEs but not many [0]. I think the better argument is that some of the original code is just really hard to read. Click around the repo [1]

[0] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

[1] https://github.com/coreutils/coreutils/

rurban2• 3 years ago

Nice, with mv/cp -g, which was rejected upstream.

Now just unorm from Assaf Gordon's multi-byte-20200607.patch is missing: https://github.com/rurban/coreutils/commit/4008663077be6a740...

The Rust Implementation of GNU Coreutils Is Becoming Remarkably Robust

Related Stories