Hacker News Reader

Comment by Rotten194 | Hacker News Reader

    ls | filter-hidden | sort | add-directory-slashes | mark-symlinks | mark-executables | colorize | display-in-grid

This seems really inconvenient, but who cares because it's ideologically sound!

View on HN

You could improve it further - on every ls spin up several hadoop instances to do your map/reduce to process the output!

Timeless reference: https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

You could make it as convenient as existing flags are, only you wouldn't have to learn a different set of flags for every cli. No need for sarcasm.

How would you make it as convenient as existing flags?

Not sure if you're being serious or not, but if I had to do it today, instead of:

I'd start with this:

`ls | nodot | sort | slash | dec | c | grid`

I imagine there's an even better way, I just haven't spent very much time thinking about it.

There's an argument that this could be even more convenient than existing flags—`slash` could work on output from other commands, like `find`—only I don't have to pull up a man page for `find` since I'm not as familiar with it as I am with `ls`. That's the idea behind this kind of composability.

If this is actually too much typing or you're not happy with the defaults, a few bash aliases would go a long way towards making this shorter. For instance, you could alias `ls` such that it colorizes, sorts, and hides dotfiles by default.

That doesn't seem more convenient than "ls -abc", whatever the flags are.

How many of those filter systems would be useful for things that aren't ls?

Also, these days the cost of doing an extra fs lookup + stat call for each file in each filter is pretty small, but if you want to run that pipeline in a directory of >100k files it might be noticeable.

The cost of the extra lookups goes away entirely if one then extends the design in the ways already discussed elsewhere on this very page. Instead of the pipeline passing along a stream of bytes, which every program then parses into a stream of filenames, the pipeline passes along a stream of objects.

Then "sort" becomes a utility that sorts a stream of objects by a chosen set of fields; "slash" becomes a utility that inspects the "file type" and "file name" field of an object and makes an appropriate "display name" field; and "ls" becomes a utility that outputs a stream of objects that have "file type" and "file name" fields, straight out of the directory entry. "ls" is the only part of the pipeline that looks at the disc.

Reply on news.ycombinator.com