Hacker News Reader

Comment by jff | Hacker News Reader

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.

View on HN

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

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.

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.

  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.

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.

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.

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.

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.

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

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

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

You should not use -exec, you should use -execdir, -exec is not safe.

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

Reply on news.ycombinator.com