
CoreUtils implemented in pure JavaScript - fidbit
https://www.github.com/dthree/cash
======
Sir_Cmpwn
>Huh? Okay - think Cygwin, except:

Oh boy, another one of these. Cygwin is useful because it provides a POSIX C
API on Windows. It is not useful because of its shell and coreutils. And
saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js
require/export patterns instead of ES6 modules.

>1/15th of the size [of Cygwin]

Haha, and 1/100th the functionality

~~~
manyxcxi
Is this indicative of what's going on in the JS world today, with all the
churn of packages and libs? Does it boil down to being sucky and not useful if
it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why
do the other things suck because they're not this?

EDIT: I've said it on other threads- I like the creativity and exuberance in
the JS community. I'm not putting it down. There's just a lot of churn/NIHS.

(I didn't seem to be getting downvoted, but I also want to be clear that I'm
not putting the community down)

END EDIT

I think it's a cool excercise. Why would I ever want to use this in the way it
is saying it should be used? Why would I ever use this period?

~~~
AnkhMorporkian
In instances like this, there's no issue with it being ES5.

However, in the web world, ES6 modules have a _huge_ (pardon the pun)
advantage that's just being realized. Because of the static nature of ES6
imports, you can eliminate unused code when you package it all together. The
newest Webpack versions and Rollup are both taking advantage of this, and it
can result in huge savings in filesize.

For example, lodash is a large library with hundreds of methods, and a lot of
the time people only use 3 or 4 imports from it. If you use an ES5 version,
you'll get all of those functions in a compiled bundle no matter what. If you
use an ES6 version with Webpack 2, all the methods you use will end up being
the only ones that are actually included in the final code.

~~~
elmigranto
I imagine most libraries has some common functions that ones from public API
rely on (and of course some exports can be used within module itself).

Let's say you never import `helperX` and `helperY` from a library, but you
import `usefulFunction` which relies on `helperX`. How would webpack know to
exclude `helperY` but not `helperX`?

Unless it does some kind of code analysis, or lib is split in "module per
function" or similar manner, I can't really see a way to achieve it. And if
library is common core plus a bunch of modules per function it exports, how is
that different in CommonJS versus ES6 modules?

Am I missing something?

~~~
zbuttram
I believe they are doing code analysis, at least that's what the README for
Rollup says:

> Rollup statically analyses your code, and your dependencies, and includes
> the bare minimum in your bundle.

~~~
frutiger
I don't think that's possible in all cases:

    
    
        var mod = {};
        module.foo = function () { return 42; };
        module.bar = function () { return -1; };
    
        module[Math.random() > 0.5 ? "foo" : "bar"]();
    

How can `Rollup` determine that I need both functions here?

~~~
AnkhMorporkian
That's why it only works with ES6 imports. ES6 imports must be made at the top
of the file, and aren't dynamic. You must explicitly import what you need.

Additionally, this method only works with named imports. So for example, you
can have two files:

File a.js

    
    
        export a = 5;
        export b = 6;
        export c = 7;
        export d = 8;
        export default {a, b, c, d};
    

File b.js

    
    
        import {a, b} from "./a.js";
    
        console.log(a);
        console.log(b);
    

c/d will never be included in the output file, nor will the default export.
However, if you do:

    
    
        import a from "./a.js";
    

Then it won't optimize at all, because all of those objects are referenced in
the default export.

Note that it's possible I'm wrong as to the specific optimization method, but
largely speaking this is how it should work.

~~~
frutiger
That much makes sense, but if I understand GGGP's example properly, they are
talking about pruning unused internal references within a module, but GGP's
response implies that somehow Rollup will prune those out.

~~~
AnkhMorporkian
Ah, I understand the confusion now. I'm not 100% sure how that code works, but
I do know it uses estree and that case is tested for, nearly verbatim. Here's
a link to the source which handles that sort of stuff.

[https://github.com/rollup/rollup/blob/6fc8631ba1aad718885151...](https://github.com/rollup/rollup/blob/6fc8631ba1aad718885151f4c2eb33596cc6fa45/src/Module.js)

------
cyphar
As far as I can see, what's been implemented is a _shell_ in JavaScript, which
emulates a bunch of coreutils by treating them as built-in keywords.

It's kinda cool I guess (I don't use Windows), I just don't get why the
tagline is "Cross-platform Linux without the suck". Apart from the phrase
"cross-platform Linux" not making sense in this context, I don't see why other
implementations inherently "suck".

~~~
karmabadger
I don't understand this at all. UNIX shells suck. Javascript sucks. How could
one implement a UNIX shell in Javascript and have it _not_ suck? Does the
result suck so bad that it just wraps around becomes good again?

Is the "way forward" recombining and rehashing the terrible technologies
everyone is familiar with already, indefinitely?

~~~
cyphar
> UNIX shells suck. Javascript sucks. How could one implement a UNIX shell in
> Javascript and have it not suck?

What do you mean by "UNIX shells suck"? I'm fairly sure most people would
consider UNIX shells to be one of the bigger revolutions in computing.

~~~
pdpi
Perhaps it's my own shortcoming, but for any given script I write, I find
that, say, 20% of all my code is productive, and the remaining 80% is
massaging the output of one tool into a shape that's compatible with the input
of the next tool. Compare with the exprience of using Windows PowerShell where
cmdlets return objects and you can grab precisely the fields you want with
minimum ceremony.

Things are better now with builtin tests, but god help you if you need to use
/bin/[ and you end up with idioms like 'if ["x$foo" = "x$bar"]' so that bad
things don't happen if $foo starts with a dash, or either variable is empty.

It gets even more fun when you look at the amount of cruft around terminal
emulators themselves, and the support for legacy terminals in the command
line. Why do modern versions of OSX still ship with /usr/lib/libtermcap.dylib?

Don't get me wrong -- UNIX shells are amazingly powerful tools, but they're
just stuck in the 70s and we can do much better today.

~~~
pjc50
I keep wanting to like PowerShell but finding it limited in silly ways. _Text_
output is crippled, and there's no sensible way to save the intermediate value
of a pipeline in a file.

The security ceremony required around PS is also an obstacle to getting
started. And of course Microsoft have missed the opportunity to fix the path
separator.

I admit that Bourne shell is not great for anything over a few lines, and find
it better to drop into perl or python where filename-separator issues are
mostly eliminated.

~~~
dsp1234
_and there 's no sensible way to save the intermediate value of a pipeline in
a file_

Sounds like you are looking for Tee-Object[0].

"Saves command output in a file or variable and also sends it down the
pipeline."

 _And of course Microsoft have missed the opportunity to fix the path
separator._

Windows supports both path separators in pretty much all cases (open files,
changing directories, etc)

    
    
      PS C:\> d:
      PS D:\> cd /projects/node_modules/immutable/node_modules/uglify-js/node_modules
      PS D:\projects\node_modules\immutable\node_modules\uglify-js\node_modules>
    

_Text output is crippled_

I guess this depends on what you want out of the system. Some options are:

"format-table -auto" which provides a nicely formatted table view of the data

"format-list" which provides each property on a separate line with a blank
line between objects

"format-custom" which allows you to create your own views of objects (with a
very readable default), which has ultimate flexibility

"converto-csv" which output the object as a CSV (or with custom delimiters
such as TSV)

"converto-html" which outputs the object as an html table (with somewhat
customizable markup)

"convertto-xml" similar to the above

But really, if it's possible, then it makes sense to use the object pipeline
until you're done (so that different parts of the pipeline can use different
parts of the object). Then spitting out CSV, TSV, XML, etc should get interop
with basically every other tool that's going to process text in some way.

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

~~~
pjc50
Text output is chopped at 80 characters unless you specify otherwise, _even
when directed to a file_ ; I'm probably going to try converto-csv next time I
want to input it into python, thanks for the tip.

The output of tee-object can't easily be read back in to a new pipeline. I
suppose we're supposed to stash it in a variable which will be good enough for
99% of cases.

------
faaef
Apart from this being of questionable usability, why do people feel the need
to solve every problem with (Node)JS? I can think about a ton of languages
better suited for systems programming at the top of the hat.

~~~
callumlocke
Because JavaScript is the most widely used language in the world.

As a web developer, I know JavaScript very well. I have already encountered
thousands of its idiosyncrasies and I am very good at making it work for me.

Therefore any tool written in JavaScript is _automatically_ easy for me to
understand and modify. If that tool could have been more elegantly written in
another language, that's awesome for people who know that other language, but
it's irrelevant to me. Even if I kind of know my way around the other
language, I'm never going to be as effective with it as the language I use
every day. And a lot of people use JavaScript every day. This is the reason
why people feel the need to solve problems in JavaScript.

~~~
striking
But JS can't solve every problem, nor can it solve certain problems well.

I understand people feel the need to solve problems in JS because they're
scared or inconvenienced by learning a new programming language.

But why not learn a new language? Having a working knowledge of C won't kill
you.

edit: could you explain how JS is the most widely used language in the world?

~~~
callumlocke
> Having a working knowledge of C won't kill you.

I do have some knowledge of C, and I could learn more. But unless I change
career, I'll always be faster and more effective in JavaScript because I think
in it all day, so I'll almost always choose JS over C. I'm not disparaging
anyone who uses C, just answering @faaef's question about why people "feel the
need" to make everything in JavaScript – because they can, they happen to know
JS very well, and because there's automatically a huge potential contributor
base.

> could you explain how JS is the most widely used language in the world?

I don't know, but I assumed it's the most widely used because websites :) Also
it's the most popular language on GitHub

~~~
striking
JS is definitely the wrong language for a number of programming projects. JS
lacks a number of features that other languages have... on its own, that
doesn't make it a bad language, but it means it's less useful for certain
projects.

Like this one. Like the POSIX API that is actually compatible with other
applications.

And by that definition of used, C and Java are pretty strong competitors,
seeing as every SIM card and Bluray player and so many more run Java... and
then there's Linux and its embedded RTOS cousins, etc., etc., that are written
in C or C++. I think embedded devices beat out JS pretty well.

------
rhinoceraptor
It's always mind blowing how when someone makes a neat project like this and
the comments are nothing but complaining, vitriol, etc.

~~~
na85
Lots of vitriol because it's yet another "I took something that works and
rewrote it to be slower, less functional, and JavaScript"

Making computing worse, one fork at a time.

~~~
rhinoceraptor
This is the attitude that drives people away from working on open source.

~~~
gherkin0
It's better to say nothing so people can be happy with what they've just done
and continue to make the same mistakes in the future?

~~~
rhinoceraptor
So I guess no one should write a toy kernel again the future, because it won't
be perfect? What kind of logic is that?

~~~
na85
Toy kernels are usually presented as such.

This is presented as Unix Without the Suck, when in fact it's almost 100%
suck.

------
solenoids
I understand why you'd use Node.js for I/O intensive tasks like web
development and scraping, but for a cross-platform program meant to do
everything? None of Node.js's benefits shine.

Sure, Node.js has a big community with lots of (mostly linux-only) packages,
but you get a mediocre language and pretty crap cross-platform support. This
doesn't matter as a web development language, but seriously gets in the way
when you're developing a program designed to do literally everything.

A more useful project might be coreutils in rust, which several projects are
already doing.

------
mbrownnyc
I'm sitting here wondering why no one ever talks about PowerShell. It supports
.NET reflection, which allows direct .NET API access. It's basically c# shell.

~~~
na85
Because then I'd have to be running Windows, which is a deal-breaker.

------
iuyoynp
how cli tools implemented in node is "without suck" is beyond me. fucken
hipsters

~~~
TickleSteve
Absolutely... Replacing a single DLL with Node is "simplifying" it.... Jeez...

------
ascotan
More validation of the Atwood principle. [http://blog.codinghorror.com/the-
principle-of-least-power/](http://blog.codinghorror.com/the-principle-of-
least-power/)

------
xbdhdhd
For what purpose?

~~~
pygy_
That would come in handy for cross-platform npm 'run' scripts.

------
Wintamute
Writing cross platform build scripts for web projects can be a pain when you
want to rely on commands like cat, rm etc. This looks like it could relieve a
lot of that. Nice job.

P.S. I'm constantly amazed by the number of non-JS developers that pile onto
JS-related HN threads to tell us how much JS sucks. I'd like there to be less
of it, it's getting a bit old. It seems like any amount of familiarity with
the web, or the fact that someone once wrote a JS function sometime makes
people feel entitled to weigh in on modern JS development. Look after your own
communities and let us plough our own furrow ... we think lots of small
modules is an interesting approach, and we'd like to see where we can get with
it.

------
TickleSteve
I never understood the hatred for Cygwin, its a (set of) DLLs that form a
POSIX->Windows translation layer.

All the bulk is just the utilities that people want to provide once they've
got that layer (i.e. CoreUtils).

------
dvh
It is easier to port shell than shell script.

------
elcapitan
I'll wait for GNU/Windows.

~~~
jordigh
That's roughly what Cygwin is, with actual GNU instead of pared-down
replacements.

------
debacle
I was very interested in contributing to this project, but the code quality of
some of the commands seems prohibitively low.

------
emdog4
Mongo(DB) shell interprets JS and it's very useful. Modifying documents,
reorganizing scheme, processing queries.

I can see the usefulness in a JS shell mainly because JS is a popular
scripting language.

Running this on Linux will be difficult because node runs with a very limited
set of permissions.

------
randommodnar
What the fuck I don't even

~~~
dang
Please post civilly and substantively, or not at all.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

------
unexistance
I hope the goals are

\- short-term : POSIX compliant

\- long-term : runs *nix binary / programs

p/s: love anything CLI, so I may be biased

~~~
ne0phyte
How would they run *nix binaries in a node.js environment if they call it
"Cross-platform Linux without the suck"? You are talking about Cygwin here
which is what these guys hate for some reason.

~~~
umanwizard
Cygwin can't run binaries compiled for non-Windows systems, can it?

