4 ms·

It's not a beautiful tool, it's an over-large conglomeration of functionality that already exists in the shell. We don't even have it in Plan 9; here's how you

by jff 15y ago

It's not a beautiful tool, it's an over-large conglomeration of functionality that already exists in the shell. We don't even have it in Plan 9; here's how you can do some of the examples I'm seeing in comments here: To just find a file: du -a . | grep filename To find every file containing the string "foo" (the awk is necessary to remove file sizes, you could combine du and awk in a shell function if desired): for (i in `{du -a . | awk '{ print $2 }'}) { grep 'foo' $i } Really, the for loop above takes care of a few of find's options. Why do you need both "-exec" and "-delete"? Exec is far more versatile, you can just exec "rm" on the files. Except that as I've shown above, it's already quite easy to execute a program for every file that matches some criteria, and you don't have to learn the dozens of options used in find--you just apply the shell programming knowledge you should (hopefully) already have.

glenjamin 15y ago
I'm inclined to agree, I have never taken the time to learn the various somewhat arcane switches you can pass to find (not to mention that it doesn't follow - for short -- for long switch convention). I simply do find <path> to give me a list of all the paths under the current directory and then pipe that into grep.
- jff 15y ago
  For that purpose, I often make a shell script called "find" containing the line "du -a | awk '{print $2}'" and stick it in my bin directory... although at this point I'm so used to using du, I even do the "du -a | grep pattern" dance on Unix.
- masklinn 15y ago
  > not to mention that it doesn't follow - for short -- for long switch convention That's because they're not options, they're predicates. A sequence of predicates to be precise (they execute strictly in-order and are short-circuited: the first predicate failure will stop the whole evaluation unless you're using `-or`). They're closer to `test`'s operator than to `grep`'s switches.
tptacek 15y ago
Your argument kind of lost me at the point where you said "the awk is necessary to". You make a well-reasoned point, but really, isn't it a slippery slope? Lots and lots of Unix tools can be further broken down into smaller extant Unix tools.
- ootachi 15y ago
  Exactly. UI is important, and even if find can be written in terms of other tools, its superior UI justifies its existence. It's sort of like SQL: a declarative interface means that a system administrator doesn't have to think how to do something, but merely of what needs to be done in order to do it. Minimalism at the expense of helping the user get the job done isn't the right tradeoff.
- shabble 15y ago
  du -a | cut -f2 is a less sledgehammery approach than requiring awk. I don't recognise the OP's shell syntax (unless it's intended more as pseudo-code), but I think at least in bash, you'd have problems with embedded whitespace in filenames. Find and Xargs have the option nul-separated output records specifically for this reason.
  - jff 15y ago
    It's Plan 9's rc shell... I didn't use cut because I've got in the habit of using awk for quick shell tasks. I'll have to remember cut, though, since awk is definitely using a sledge to drive in a thumbtack. Also in Plan 9, we typically don't have spaces in file names, but I think when we do they come out quoted... as far as I know there's no xargs.
a3_nm 15y ago
I agree that the find command isn't minimalistic and could be simplified, but the use of du in this case semes pretty ugly if you're not interested in the file sizes. A lightweight find would probably be a better solution.
masklinn 15y ago
> It's not a beautiful tool, it's an over-large conglomeration of functionality that already exists in the shell Find absolutely is a beautiful tool. It does one and only one thing: apply predicates to the file system. > du -a . | grep filename Except that's going to match on the dirname content as well, whereas `find -type f -name filename` will only match the actual file name. And you're going to get complete junk in the first section of each line which you'll have to cleanup afterwards. > (the awk is necessary to remove file sizes, you could combine du and awk in a shell function if desired) Right, whereas if you use `find` it gives exactly what you want (or need) > Why do you need both "-exec" and "-delete"? You don't need both, but -delete provides additional clarity and forces depth-first traversal. > Except that as I've shown above, it's already quite easy to execute a program for every file that matches some criteria Except your examples are all broken since you're not using `basename`. Turns out it's not that easy, and it soon becomes complete shell-soup. > and you don't have to learn the dozens of options used in find They're not actually options, they're predicates.
code_duck 15y ago
The first example is exactly how I search for things, because I can never get the right syntax for find.
rhdoenges 15y ago
I use find for one thing and one thing only--listing all the files under the current directory. du works, but I prefer find. find | while read i; do grep 'foo' $i; done
ars 15y ago
That's going to fail if you have a file with a newline in it. And what are you going to do when you want to find all files modified more then 32 hours ago? -delete is necessary because otherwise there is a race condition which can allow a regular user to make root delete any file. See: http://news.ycombinator.com/item?id=2699050 http://news.ycombinator.com/item?id=2699050 You should not use -exec, you should use -execdir, -exec is not safe.

by jff 15y ago

glenjamin 15y ago

I'm inclined to agree, I have never taken the time to learn the various somewhat arcane switches you can pass to find (not to mention that it doesn't follow - for short -- for long switch convention). I simply do find <path> to give me a list of all the paths under the current directory and then pipe that into grep.

jff 15y ago
For that purpose, I often make a shell script called "find" containing the line "du -a | awk '{print $2}'" and stick it in my bin directory... although at this point I'm so used to using du, I even do the "du -a | grep pattern" dance on Unix.
masklinn 15y ago
> not to mention that it doesn't follow - for short -- for long switch convention That's because they're not options, they're predicates. A sequence of predicates to be precise (they execute strictly in-order and are short-circuited: the first predicate failure will stop the whole evaluation unless you're using `-or`). They're closer to `test`'s operator than to `grep`'s switches.

tptacek 15y ago

Your argument kind of lost me at the point where you said "the awk is necessary to". You make a well-reasoned point, but really, isn't it a slippery slope? Lots and lots of Unix tools can be further broken down into smaller extant Unix tools.

ootachi 15y ago
Exactly. UI is important, and even if find can be written in terms of other tools, its superior UI justifies its existence. It's sort of like SQL: a declarative interface means that a system administrator doesn't have to think how to do something, but merely of what needs to be done in order to do it. Minimalism at the expense of helping the user get the job done isn't the right tradeoff.
shabble 15y ago
du -a | cut -f2 is a less sledgehammery approach than requiring awk. I don't recognise the OP's shell syntax (unless it's intended more as pseudo-code), but I think at least in bash, you'd have problems with embedded whitespace in filenames. Find and Xargs have the option nul-separated output records specifically for this reason.
- jff 15y ago
  It's Plan 9's rc shell... I didn't use cut because I've got in the habit of using awk for quick shell tasks. I'll have to remember cut, though, since awk is definitely using a sledge to drive in a thumbtack. Also in Plan 9, we typically don't have spaces in file names, but I think when we do they come out quoted... as far as I know there's no xargs.

a3_nm 15y ago

I agree that the find command isn't minimalistic and could be simplified, but the use of du in this case semes pretty ugly if you're not interested in the file sizes. A lightweight find would probably be a better solution.

masklinn 15y ago

> It's not a beautiful tool, it's an over-large conglomeration of functionality that already exists in the shell Find absolutely is a beautiful tool. It does one and only one thing: apply predicates to the file system. > du -a . | grep filename Except that's going to match on the dirname content as well, whereas `find -type f -name filename` will only match the actual file name. And you're going to get complete junk in the first section of each line which you'll have to cleanup afterwards. > (the awk is necessary to remove file sizes, you could combine du and awk in a shell function if desired) Right, whereas if you use `find` it gives exactly what you want (or need) > Why do you need both "-exec" and "-delete"? You don't need both, but -delete provides additional clarity and forces depth-first traversal. > Except that as I've shown above, it's already quite easy to execute a program for every file that matches some criteria Except your examples are all broken since you're not using `basename`. Turns out it's not that easy, and it soon becomes complete shell-soup. > and you don't have to learn the dozens of options used in find They're not actually options, they're predicates.

code_duck 15y ago

The first example is exactly how I search for things, because I can never get the right syntax for find.

rhdoenges 15y ago

I use find for one thing and one thing only--listing all the files under the current directory. du works, but I prefer find. find | while read i; do grep 'foo' $i; done

ars 15y ago

That's going to fail if you have a file with a newline in it. And what are you going to do when you want to find all files modified more then 32 hours ago? -delete is necessary because otherwise there is a race condition which can allow a regular user to make root delete any file. See: http://news.ycombinator.com/item?id=2699050 http://news.ycombinator.com/item?id=2699050 You should not use -exec, you should use -execdir, -exec is not safe.