5 ms·
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 t
by JasonSage 10y ago
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.
- Rotten194 10y agols | 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!
- JasonSage 10y agoYou 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.
- flukus 10y agoHow would you make it as convenient as existing flags?
- JasonSage 10y agoNot sure if you're being serious or not, but if I had to do it today, instead of: `ls | filter-hidden | sort | add-directory-slashes | mark-symlinks | mark-executables | colorize | display-in-grid` 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.
- flukus 10y agoThat doesn't seem more convenient than "ls -abc", whatever the flags are.
- pjc50 10y agoHow 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.
- JdeBP 10y agoThe 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.
- nottorp 10y agoYou 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-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
- bigger_cheese 10y agoI 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.