
Cross-platform Rust rewrite of the GNU coreutils - yincrash
https://github.com/uutils/coreutils
======
ignoramous
Rust is a great choice for systems programming it'd seem. Esp considering that
a well-tested, battle-hardened code-base like SQLite faces problems [1] solely
due to the nature of the language its written in.

[1]
[https://news.ycombinator.com/item?id=11312918](https://news.ycombinator.com/item?id=11312918)

~~~
thegeomaster
Not sure why you're being downvoted. I don't see why we shouldn't be moving to
languages like Rust given the chance, as C makes it far more difficult to
write safe and correct code.

~~~
masklinn
I expect it's because because the first part is essentially preaching to the
choir, and because Richard Hipp very much disagrees with the second part[0]

> Rewriting SQLite in Rust, or some other trendy “safe” language, would not
> help. In fact it might hurt.

(see link for expansion on that matter, which is a question of tooling and
testing)

[0]
[http://blog.regehr.org/archives/1292#comment-18452](http://blog.regehr.org/archives/1292#comment-18452)

~~~
pcwalton
Disappointing to see Hipp make that argument. It's trivially refuted.

Yes, all programming languages allow the programmer to write bugs. But
languages very much vary in _how many_ , and _what kinds_ of bugs programmers
write _in practice_. Saying "well, Rust doesn't eliminate all bugs" is
attacking a straw man. If you want to argue that Rust isn't worth it, you need
to convince me that C plus gcov results in fewer bugs in the important areas
_in practice_ than Rust (plus kcov [1] if you like) does. I think that's going
to be pretty hard. (Especially if memory safety issues are the most important
bug class you're concerned about: I think it's completely impossible for any
C-based solution to compete with Rust here, regardless of how much tooling you
add.)

Drawing an equivalence between undefined behavior and compiler bugs also
doesn't make sense. Compiler bugs are _way way less commonly encountered_ than
undefined behavior in C. Also, they're qualitatively different: compiler bugs
get fixed in new compiler versions, while UB is by design and doesn't get
fixed.

[1]: [https://users.rust-lang.org/t/tutorial-how-to-collect-
test-c...](https://users.rust-lang.org/t/tutorial-how-to-collect-test-
coverages-for-rust-project/650)

~~~
weberc2
> If you want to argue that Rust isn't worth it, you need to convince me that
> C plus gcov results in fewer bugs in the important areas in practice than
> Rust (plus kcov [1] if you like) does.

I don't have a dog in this fight, but I don't see how the burden of proof is
on Hipp rather than the folks proposing the change. In other words, shouldn't
the "rewrite it in Rust" folks have to prove that the cost of their proposed
rewrite will be justified?

~~~
andrewflnr
Sure, the primary burden of proof is on those proposing a change. However,
_any_ time you stand up and make an argument, the burden is on you to make
sure it actually makes sense, and that goes for both sides.

~~~
viraptor
This is getting a bit meta, but I disagree. It would be trivial to abuse in
discussions.

    
    
        A: Bash would be way better for SQLite, really!
        B: But Bash is a terrible choice because X, Y, Z, ...
        A: If you make those arguments, you have to prove them.

~~~
lotyrin
"Bash would be terrible because using it would cause a fire"

Yes, arguments have a burden to make sense, and provide evidence...

------
gkya
> Many GNU, Linux and other utils are pretty awesome, and obviously some
> effort has been spent in the past to port them to Windows. However, those
> projects are either _old_ , abandoned, _hosted on CVS_ , written in
> platform-specific C, etc.

I have seen such a paragraph in another projects README, IIRC a Go rewrite of
standard utilities. I do not understand why a project would be obsolete
because it's on CVS or is old. CVS is simpler than Git, albeit less capable.
I, for one prefer it over Git for this reason, and others may do so too. Why
would the end user care?

And why would we care about the age of a programme if it works?

Now, that said, the authors need not justify anything, they are free to do
whatever they want, and I guess it's fun to code this stuff. I tried this just
to play with Golang when it was 1.1.

And lastly, that Makefile is really a bunch of shell scripts, and some common
environment variables. There is no real dependency tracking in it, and it is
easier to maintain a bunch of shell scripts than a seriously ugly and complex
Makefile like this. N.b. that when I say dependency tracking I mean
dependencies among input and output files of processing commands, not tasks. I
guess Cargo would know how to do that, and how to not build if the build
artefact is already there. It's a useless use of make. And that makefile is
very GNU-specific, not complying with a project whose purpose is to be cross-
platform. Also, I guess, tho I'm really unfamiliar with Rust and Cargo, if
that makefile was removed, maybe on Windows they'd be able to drop development
dependencies on Cygwin or Msys.

~~~
micampe
I could see preferring svn to git because of the simpler model, but _cvs_? No
thanks, a vcs without atomic commits is not much better than snapshot
archives, maybe worse actually.

~~~
gkya
For my use case, it's way more preferrable:

a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so
simple and easy, a half-arsed programmer like me can actually _understand_ it.
Things like git and mercurial are way more complex.

b) RCS is real handy for single files, e.g. a free-standing text file or shell
script. But when the thing grows up, it is very easy to integrate the fileset
into a CVS repo preserving it's history: move the ,v files to
$CVSROOT/$MODULE/.

c) The repository model of CVS is as transparent as it gets.

d) The keywords like $Id$ are really useful.

e.g. I keep my system configuration in "~/Checkouts/system-config", and I have
a script that cp's the files to appropriate locations using a map file. When
I'm not sure if the active config is not up to date, I can verify very easily.
And I can be sure that dirty files won't be active as long as I don't
expressly copy them. I know that SVN has this too, but I find CVS easier to
use in general.

I guess for fast paced, very active development, yes CVS is sub-par, but for
personal stuff, or for something that is patched say at most two-three times a
month, it's O.K. It boils down to personal preference.

~~~
aidenn0
SVN is way simpler at the interface than CVS, you should really look into it.
SVN is a spiritual successor to CVS, and is trivially easy for a CVS user to
pick up. We switched from CVS to SVN at work several years ago and everyone
was happy with the change.

~~~
zwischenzug
We did the same and plenty were _unhappy_. In the end git took over.

There were plenty of things I didn't like about SVN (separate folders per
branch? yuk), having used CVS, and didn't find it 'trivial' to pick up.

~~~
aidenn0
Really, it's hard to handle branching worse than CVS does, and if SVN doesn't
do a stellar job either, I don't see it as a barrier to switching.

------
rhelmer
Redox has been working on smaller, more BSD-like versions of the basic Unix
utilities, also written in Rust:

[https://github.com/redox-os/coreutils](https://github.com/redox-os/coreutils)

I am excited to see this as I was working on a similar project last year
(rewriting the BSD userland in Rust), but it's from pre-1.0 Rust so not really
as idiomatic as what is coming out of the Redox project.

~~~
spaceheeder
From the README: "These are based on BSD coreutils rather than GNU coreutils
as these tools should be as minimal as possible."

If all of these utilities are running in userspace, per Redox's microkernel
architecture, then what is the advantage of intentionally _not_ making them
feature-rich?

~~~
icebraining
It has the advantages that come from following the UNIX style. To learn more,
I recommend reading this short paper by Rob Pike and Brian Kernighan,
published in 1984:
[http://harmful.cat-v.org/cat-v/unix_prog_design.pdf](http://harmful.cat-v.org/cat-v/unix_prog_design.pdf)

~~~
spiralpolitik
"Those days are dead and gone and the eulogy was delivered by Perl" \- Rob
Pike (2004)

------
codedokode
Though I like ideas behind Rust but the code is awful. If you look at the code
you'll see a lot of misterious symbols (as in Perl) and strange constructs
like wrap, unwrap, Arc etc. They make the code less readable.

Also Rust doesn't have exceptions so you have to wrap almost any function call
with let/match/Ok/Err. Ugly.

I looked at one random file which turned out to be a `du' command
implementation:
[https://github.com/uutils/coreutils/blob/master/src/du/du.rs...](https://github.com/uutils/coreutils/blob/master/src/du/du.rs#L89)

Are they really starting a new OS level thread for every directory found?
Looks like an easy way to exhaust system resources to me. Also I don't see the
code that would collect error information if if the thread panics.

~~~
0xFFC
>Also Rust doesn't have exceptions so you have to wrap almost any function
call with let/match/Ok/Err. Ugly.

respectfully, This is pure nonsense.

First of all rust does not have runtime and AFAIK for providing exception you
should have runtime to manage stack.

Second not every language should be like high-level languages, it is not the
_rule_ to be like C#,Java,Python,etc. I use a lot of them for my work when I
need simple thing to do, but rust designed to do low-level stuff, and I cannot
understand how having not having exception makes a language ugly (specially
when you code in lowlevel).

~~~
codedokode
I mean if you have to write that match construct around every function call
the code quickly gets bloated, doesn't it? And that is not good.

~~~
masklinn
> I mean if you have to write that match construct around every function call

Not quite.

1\. you're supposed to handle errors around function calls which can fail,
which is a strict subset of "every function call"

2\. rust has a number of higher-order constructs to facilitate that
handling[0][1][2], not just raw `match` statements or expressions.

That aside, for rust explicit error handling is considered a feature both at
the language level (allows for less runtime requirements and much stronger
guarantees — check out exception-safe C++ for what happens when low-level
meets exceptions) and at the user level (by forcing a conscious and explicit
decision, whether it's crashing the system, handling the error or passing the
ball upwards)

> the code quickly gets bloated, doesn't it?

Does C code quickly get bloated? Because you're also supposed to check for
error codes after each function call which can fail, and C doesn't provide
much abstractive power to mitigate that.

[0] [http://doc.rust-lang.org/std/result/enum.Result.html](http://doc.rust-
lang.org/std/result/enum.Result.html)

[1] [http://doc.rust-lang.org/core/macro.try!.html](http://doc.rust-
lang.org/core/macro.try!.html)

[2] [https://github.com/rust-lang/rfcs/pull/243](https://github.com/rust-
lang/rfcs/pull/243)

------
masklinn
Rewriting coreutils is neat, but a project I'd really look forward would be a
strict POSIX base expanded with warnings or errors on valid but risky
constructs e.g. echo -n. Even more so if it included a shell (with static
analysis of useless uses and dangerous patterns). That would make writing
cross-shell scripts much easier.

~~~
gjem97
Ok, I'll bite. What's wrong with "echo -n"?

~~~
masklinn
[http://www.in-ulm.de/~mascheck/various/echo+printf/](http://www.in-
ulm.de/~mascheck/various/echo+printf/) is the raw data version.

POSIX defines echo as only taking string parameters and no options, but notes
that behaviour facing `-n` is implementation-defined.

BSD and GNU echo implement `echo -n` as not printing a trailing newline, but
`echo` commonly calls to a shell builtin which may or may not follow that
behaviour (and may switch behaviour depending on whether the shell is in "sh
mode" or not), so `echo -n` could print `-n<newline>` or nothing whatsoever
(empty string and suppressed newline) depending on the utils set, the shell,
and the shell's runmode.

GNU echo also supports -e, -E, --version and --help options, and much like -n
shells and other utils set may or may not support these.

For instance on my machine (OSX 10.11)

* zsh (builtin) interprets -e, -E and -n as options (but not version or help)

* bash (builtin) also does, except when invoked as sh in which case it does not and all parameters are literal (this may also apply to zsh)

* dash (builtin) interprets -n, but none of the others. bash note may also apply to it.

* BSD echo interprets -n but will print -e, -E, version and help literally

* GNU echo interprets all of the above

So if you use echo with any non-literal parameter, or with one of the
parameters listed above, in a script you distribute to un-controlled third-
parties as an sh script (rather than e.g. a bash or zsh script specifically)
you will suffer from portability issues.

And that's just for measly trivial echo (and incidentally why you should
always use printf rather than echo in scripts you try to make portable).

~~~
ape4
Whoever wrote the POSIX spec was too conservative. -n should mean no
newline(s). Anything else is wrong.

~~~
gkya

      ECHO(1)                 FreeBSD General Commands Manual                ECHO(1)
      
      NAME
           echo — write arguments to the standard output
    

For this definition, -n should mean merely a sequence of two bytes to be
written to stdout. Why not just use printf instead? It is way more flexible
and powerfull, and "printf x" always prints "{'x', 0}";.

------
alixaxel
The CoreUtils sort is amazingly efficient, it can sort files nearly as big as
your hard drive without matching memory requirements.

With all these node.js / Go / Rust CoreUtils implementations I'm still hoping
for one of them to actually match the efficiency of the original
implementation.

~~~
yincrash
I wrote the initial sort about a year ago (w/o looking at GNU version's
source). I just looked at the current version, and confirmed uutil's sort does
not do any external sorting, meaning the entire input is stored in memory.
Maybe someone can confirm that GNU's sort uses temporary file storage to do
something like an external merge sort to reduce memory usage?

edit: confirmed. [http://stackoverflow.com/questions/930044/how-could-the-
unix...](http://stackoverflow.com/questions/930044/how-could-the-unix-sort-
command-sort-a-very-large-file)

------
mapleoin
What are the licensing implications for this kind of work? I assume the
authors used GNU coreutils as more than just inspiration. They probably read
all the original code and reused some of the solutions (obviously ported to
Rust).

Shouldn't the derivative work still be covered by the GPL?

~~~
jeena
Just to give an example:

[https://github.com/uutils/coreutils/blob/master/src/whoami/p...](https://github.com/uutils/coreutils/blob/master/src/whoami/platform/unix.rs)

looks suspically simmilar to:

[http://code.metager.de/source/xref/gnu/coreutils/src/whoami....](http://code.metager.de/source/xref/gnu/coreutils/src/whoami.c)

~~~
kbenson
I'm not sure picking a program where the portion that does any actual work is
3-6 lines in length is a good reference for whether they are copying
code/algorithms. There's so little of substance to actually do differently,
the chance of them looking similar in that respect if fairly high.

------
z3phyr
Rust is a fine language, no doubt. What worries me is the exact rewrite of the
C code using the unsafe construct.

Also a little out of topic; Can more light be shed by fellow HNers on the
debugging tools for rust, the debugging experiences from the security research
point of view?

~~~
steveklabnik
It looks like there are 134 instances of 'unsafe', in 23,000 lines of Rust.
And it looks like a lot of that unsafe is to FFI into libc.

Rust works with GDB, so you end up debugging like anything else. IDE
integration is being actively worked on, and sorta-kinda works in my
understanding.

~~~
jblow
What is the roadmap on getting rid of the need for libc? Given how terrible
libc is, I personally would make that a high priority, though I guess in Linux
you can't even start up a process without libc (maybe that is a
misunderstanding?), which makes the situation less clean, but at least you
could get to a point where you never call back into it after entry into main.

~~~
alricb
Do you suggest they should use raw system calls? On most systems your options
are either calling standard C functions or doing raw calls (not portable).

Someone did start a C stdlib implementation in Rust, but it appears to be
inactive: [https://github.com/mahkoh/rlibc](https://github.com/mahkoh/rlibc)

~~~
jblow
Yes, the right thing is to port your language's standard library to whatever
operating system you want to run on ... just like libc did.

You could have a dummy version that just calls out to libc, for compatibility
with systems that you haven't finished porting to yet.

~~~
Rusky
And what about systems that don't have a stable interface below dynamically
linking that platform's system-provided libc? Just let every program break
when the system updates?

------
gravypod
I'd really love to use rust, given the large growth of projects like this. I
only need an IDE to get started, but it seems like there isn't one yet.

Anyone have any pointers on where I can find a good IDE for Rust? Should I
just start praying to lord-JetBrains for something that works?

~~~
niccaluim
If you've never programmed without an IDE I _strongly_ encourage you to give
it a go. You'll learn a lot!

[Good lord, a downvote on this? I'm being completely sincere.]

~~~
saosebastiao
I learned how to program without an IDE, and I'm a pretty big fan of it. And
strongly typed functional languages with type inference tend to be really easy
to write and refactor without needing specialized IDE tasks for the job.

That being said, nowadays I use an IDE because it is extremely helpful to have
autocomplete (which is _okay_ with Racer+Vim, but kinda hacky) as well as the
hover for type information (name of types, type signature, etc.). Without the
hover information, I usually end up doing ridiculous things like writing bogus
explicit types to see what type an undocumented function from a library will
return after compiling (Is it Option? or Result?). That is _really_ annoying.

I didn't downvote you BTW.

~~~
steveklabnik
[this post was wrong]

~~~
dikaiosune
Isn't it the other way around? One can downvote a post and then reply to it,
but can't downvote replies to one's own post?

~~~
steveklabnik
Gah, you're right.

------
jamescun
Could be useful given the choice of MIT license rather than a GPL variant.

~~~
davexunit
They really should use the GPL and not a pushover license.

~~~
quotemstr
What is it with rewrite-the-world-in-Rust people being stridently anti-
copyleft?

~~~
cyphar
I don't understand it either. It's as though they want to ignore the history
of free software, which simply wouldn't have happened without copyleft.

~~~
kps
Tautologically, it wouldn't have happened _as it did_ , but free software long
predates the FSF.

~~~
cyphar
Sure, but the FSF and the GNU project were reactions to proprietary software
becoming more common. Free software wasn't recognised as such until Stallman
saw the issue and decided to act. Saying that "free software existed before
the FSF" is ignoring the fact that free software would've died almost entirely
without the FSF and GNU.

------
fsiefken
Some people worry about the file size (which should be similar), but I worry
about the speed. How much faster can we grep or sed with a Rust compiled grep
vs a C compiled grep?

~~~
teamhappy
Likely not as fast as with a grep written in C, but FreeBSD's grep is (was?)
pretty slow compared to the GNU version and nobody really cares (read: it's
probably fast enough).

~~~
steveklabnik
There shouldn't be any theoretical reason that a Rust grep should be slower
than a C grep. In practice, a rust grep would be a new code base, and the
existing grep has seen a lot of development over years.

------
jffry
See also today's discussion of `cash` ("CoreUtils implemented in pure
JavaScript"):
[https://news.ycombinator.com/item?id=11334597](https://news.ycombinator.com/item?id=11334597)

------
pjc50
The rationale talks about easy portability to Windows, but I'm skeptical - the
underlying API and filesystem is different enough that this is likely to cause
problems. '\' vs '/' to start with.

~~~
Someone1234
Windows supports forward-slash fine. Has for at least 25 years. No need to
change / to \ or visa versa.

Now obviously any Windows port would have to call Win32 APIs instead of POSIX
APIs (unless you're writing for a Cygwin-like layer).

~~~
2Xheadpalm
Supported, just but it's a second class citizen, for example, no tab
completion of directories on the cmd prompt when using forward slash. Some
commands will not except it;

e.g. type c:\home\foo.txt -> cats it out type c:/home/foo.txt -> 'The syntax
of this command is incorrect.'

whereas cd will except either forward or backslash

cd c:\home/foo cd c:/home/foo

work as expected.

~~~
Someone1234
Firstly I was talking about API support. Since that is the topic at hand.

Secondly, Cmd is deprecated. Powershell supports both slashes and "type
c:/home/foo.txt" works perfectly.

~~~
ktRolster
But Powershell redirects < and > either don't work or can corrupt your files

~~~
Someone1234
You might find this useful:

[https://technet.microsoft.com/en-
us/library/hh847746.aspx](https://technet.microsoft.com/en-
us/library/hh847746.aspx)

~~~
ktRolster
A) That's only one direction, the other way doesn't work

B) Even going that direction, at times it corrupts the data

------
spaceheeder
Written in Rust, MIT-licensed, designed to be portable...I wonder if this is
something that might eventually get merged into Redox?

~~~
steveklabnik
Redox uses a different, BSD style coreutils, not GNU style.

~~~
spaceheeder
Please pardon my ignorance, but what are some of the key differences?

~~~
steveklabnik
I am not an expert, but the general difference, in my understanding, is that
the BSD coreutils is significantly "lighter", both in features and in code
size.

------
Tunabrain

        (on Windows use MinGW/MSYS or Cygwin make and make sure you have rustc in PATH)
    

This made me chuckle - if you have MSYS installed, which already comes with a
windows port of coreutils, why would you want to use it to build a windows
port of coreutils?

~~~
nwah1
Because you don't trust the memory safety of programs written in C. Or because
you think the coreutils would progress faster with a language with modern
semantics like Rust.

------
joejev
It is a bit ironic that these "gnu" core utils are not licensed under the GPL

------
kazinator
Complete rubbish: _Many GNU, Linux and other utils are pretty awesome, and
obviously some effort has been spent in the past to port them to Windows.
However, those projects are either old, abandoned, hosted on CVS, written in
platform-specific C, etc. Rust provides a good, platform-agnostic way of
writing systems utils that are easy to compile anywhere, and this is as good a
way as any to try and learn it._

Cygwin has a complete, up-to-date port of the Coreutils for Windows.

The POSIX + C language provides a a good, platform-agnostic way of writing
systems utils that are easy to compile anywhere.

~~~
dikaiosune
Is the cygwin port just some different build files, or is it genuinely
different code? A Rust codebase probably wouldn't (in most cases) need to be
modified to run on different supported platforms.

~~~
frutiger
I'm not going to comment about cygwin (because its build process is not as
transparent) but instead about msys2, the spiritual successor to cygwin. See
for yourself:
[https://github.com/Alexpux/MSYS2-packages/blob/master/coreut...](https://github.com/Alexpux/MSYS2-packages/blob/master/coreutils/PKGBUILD)
is the `pacman` style `PKGBUILD` used to build the `coreutils` package.

~~~
dikaiosune
That looks pretty clean, but they're still applying looks like 5 patches which
would need to be maintained separately. It's certainly not as bad as a full
port, but it's still not the same codebase. Rust's cross-platform efforts
would (I think?) obviate that process.

~~~
kazinator
But, nevertheless, it's not exactly a port of Coreutils to Windows _per se_.

For instance, let's take the "cp" utility.

A Windows port "cp" should be able to copy Windows-specific file attributes.
Does the Cygwin "cp" do that? How about NTFS forks?

I don't believe that you can write some portable code in Rust, and have a "cp"
utility which correctly handles every quirk of every OS's file structure.

~~~
dikaiosune
Not familiar with Windows' filesystem APIs, but the description for the Rust
function in the stdlib is here:

[https://doc.rust-lang.org/std/fs/fn.copy.html](https://doc.rust-
lang.org/std/fs/fn.copy.html)

Seems like it should handle platform specific attributes?

------
berkut
"easy to compile anywhere"

Doesn't this imply there needs to be the Rust compiler / Cargo (if it needs
that) installed on the system? And what versions - stable / unstable ?

------
Animats
Yes! No more buffer overflow exploits in the core utils.

------
yeukhon
This is actually a surprisingly good place to learn utils and learn how to
write Rust...

------
randhnuser
Offtopic: I'm currently indulging myself in clojure but as I only know dynamic
high-level languages I am also a bit curious about low-level stuff.

For someone starting at zero, would you recommend C rather than Rust or the
other way around?

------
CiPHPerCoder
Observation:

[https://github.com/uutils/coreutils/blob/master/LICENSE](https://github.com/uutils/coreutils/blob/master/LICENSE)

GNU coreutils is GPL, this is MIT.

------
acqq
How big are the executables when compiled, especially compared to the C
versions?

I hope it's not Rust version 2 MB, C version 6 KB.

~~~
steveklabnik
Well, that would be a statically linked Rust version vs a dynamically linked C
version. Either of those languages can produce binaries of either size.
Statically link a MUSL libc and it'll be bigger than 6kb, dynamically link the
rust code and use the system allocator instead of jemalloc and it'll be
smaller than 2MB. (Or rather, it should be, I haven't literally tried it. The
smallest known Rust executable is 151 bytes.)

~~~
acqq
That's what I wanted to hear, could really the mentioned in Rust implemented
coreutils be compiled and linked equivalently to C or not and can we see the
resulting sizes? Not "if I don't use any library I can get the 151 byte
binary" but exactly these coreutils that are presented.

It gives a good idea if the replacements can actually be comparable
replacements.

The second part is then to compare the number of features implemented and the
behavior.

------
jorgecastillo
I love UNIX too much, nothing can replace C in my heart! :)

------
botw
does GNU coreutils include sed/awk?

------
alphacome
which company is using Rust?

~~~
steveklabnik
There's a lot of startups that you may or may not have heard of, but the most
well-known company using Rust in production today is Dropbox.

------
faaef
It certainly beats using NodeJS.

EDIT: Yea, this was meant as a reference to the coreutils-in-nodejs post on
the frontpage.

~~~
plugnburn
NodeJS is for applications, Rust is for system programming. How does one beat
another?

It's akin to saying "ARMv7 assembly beats using Java for Android programming".

~~~
grok2
He is probably referring to this:
[https://news.ycombinator.com/item?id=11334597](https://news.ycombinator.com/item?id=11334597)
\-- discussion on CoreUtils in Javascript!

~~~
plugnburn
Ah, understood.

I think neither of these beats actual coreutils and their support base (still
under impression of Termux capabilities...), at least not yet.

------
gbersac
Is there a real need for this project ? I mean, this project has been used for
a long time, could it really be better ? Do you intend to replace GNU
coreutils ?

Not to be mean, just a genuine question (and yes I read the Why section of the
readme).

~~~
stepvhen
Multiple people have sought to rewrite coreutils, whether it be for fun,
exercise, or out of frustration with the current utils. I know folk on 4chan's
/g/ were rewriting them once, and the people at suckless are trying to do the
same, only with a lot of options and features stripped out due to "bloat" (my
word not theirs).

Your second question presumes that just because something is old means it is
the best. Traditional things can indeed work out well, but challenging
tradition is how progress is made. And you can't know if the coreutils can be
improved if you don't try, right?

~~~
gbersac
It is a rewrite of gnu coreutils because cureutils sucks. It is a good reason
!

I guess it doesn't intend to be a 1:1 rewrite of coreutils then ? The public
available function to users will be rewrote.

------
randommodnar
MIT license? Is open-source dying?

~~~
mc808
I was going to say it only takes about 30 seconds to fork and change the
license if you want to. Then I decided to check if someone had already done
so. Yep.
[https://github.com/ivegotasthma/coreutils/commit/4c7dcbd912a...](https://github.com/ivegotasthma/coreutils/commit/4c7dcbd912a78fda77900806c8bb3a59335b2d6d)

I didn't count, but that may have taken less than 30 seconds.

~~~
biot
Is that valid? The original license had:

    
    
      > The above copyright notice and this permission notice shall be
      > included in all copies or substantial portions of the Software.
    

As those have now been stripped away, it seems like a license violation.

~~~
kps
You don't have to be a lawyer to recognize that as a genuine bona fide
electrified six-car copyright violation. You just have to be able to read.

