4 ms·

Not 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-exe

Not 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 ago
That doesn't seem more convenient than "ls -abc", whatever the flags are.
pjc50 10y ago
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.
- JdeBP 10y ago
  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.

flukus 10y ago

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

pjc50 10y ago

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.

JdeBP 10y ago
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.