5 ms·
Even the traditional Unix tools don't follow the Unix Philosophy extremely well. ls is a prime example: It has too many ways to sort and format its output. It "
by msla 9y ago
Even the traditional Unix tools don't follow the Unix Philosophy extremely well. ls is a prime example: It has too many ways to sort and format its output. It "should", in the Unix Philosophy sense, simply list things in a directory and leave sorting and formatting to other tools.
However, parsing the output of ls is generally a bad idea, as it's meant for human consumption, so ls breaks another tenet: It isn't very composable, as it is difficult to use it in a pipeline, even though it should be a prototypical source program.
- hprotagonist 9y agoand `find` has practically re-implemented half the rest of the toolchain. last week i discovered the `-delete` flag. For years, i had been doing `find <stuff> | xargs -rm` instead.
- jff 9y agoI don't even bother using 'find' to actually find files. 'du -a <path> | grep <name>' works easily enough and I don't have to remember find's weird syntax.
- sametmax 9y agoI use the ffind program instead. It's just so much easier with saner defaultq.
- eridius 9y agoA better alternative to xargs is `find <stuff> -exec rm {} +` (though of course -delete is simpler).
- barrkel 9y agoI'm not sure there's much upside in using -delete, -exec etc. from find since they're redundant and can be replaced by composition; half the time, I want to stick a grep -v in there between the found paths and the execution, so xargs is usually handier than not. (I have a tool called print0 which converts line terminators to nulls, so I can use xargs -0 along with grep etc. without needing to use -print0.)
- woliveirajr 9y agoBut there are cases where `-delete` or `-exec` aren't enough, and xargs allows better handling.
- flukus 9y agoFor that matter, why do we need xargs and not just `find <stuff? | rm`?
- Asooka 9y agoI'd argue there's a difference between plumbing commands and UI commands. ls is strictly a UI command, a sort of mini-language to quickly and efficiently explore the file system. If ls didn't exist as a binary, we'd all have an ls bash function in our .bashrc that does the same thing with some perverse combination of for, globs, and stat. If you ever pipe the output of ls to anything (barring very simple cases), you're probably doing it wrong and should switch to find -exec stat instead.
- vidarh 9y agoTry to replace ls with something that acts subtly different (or just give one precedence in your path) for a few weeks and you'll see a surprising amount of stuff calls out to ls. I agree it's a bad idea (or if you do, at the very least make sure you're calling out to /bin/ls...), but it certainly happens.
- twoodfin 9y agoThe original authors of the Unix tools agreed back at least as far as 1983 that the traditional suite was growing new features inconsistent with the Unix Philosophy. Rob Pike's "cat -v Considered Harmful" presentation and associated paper are classics: http://harmful.cat-v.org/cat-v/ http://harmful.cat-v.org/cat-v/
- int_19h 9y agoThis goes to show why machine-readable output is an important thing to make processes composable. Have a look at libxo, which tries to fix this exact issue. FreeBSD adopting it in the base system is encouraging. I hope Linux follows suit, as well.