Hacker News Reader

Comment by JasonSage | Hacker News Reader

The alternative is not to write multiple `ls` commands. The alternative is to let `ls` list directory contents and to leave filtering, sorting, or customizing the output display to a separate utility which specializes in those.

View on HN

    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!

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.

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...

I think it's the old micro vs monolitihc argument.

If you rely on communication between external utilities you have to be pretty clear where you draw the line - I don't want to end up with javascript like leftpad debacle on my command line apps.

Reply on news.ycombinator.com