5 Days of find: The Basics of find | Hacker News Reader

5 Days of find: The Basics of find

bashshell.net

8 pointsaweber8 comments

Looking for files in the article is completely broken. To look for a file named syslog.conf, you need to say

    find -name syslog.conf

otherwise find will not look for that filename in all subdirectories.

So the shown

    find /etc/*.conf

is only doing the equivalent of

    ls /etc/*.conf

unless there is a directory the name of which ends in ".conf", in which case all its contents will be listed recursively. The required find command is:

    find /etc -name \*.conf

And what "find / syslog.conf" is doing is to list all files and directories in /, going down subdirectories recursively, and list syslog.conf in the current directory. What should really be used is:

    find / -name syslog.conf

which returns something like:

    /etc/syslog.conf

You are right, the commands in the article definitely don't produce the results which are claimed.

To be aware of - sometimes the shell will glob the wildcard you're trying to pass to find.

For example, if you're in a directory that contains a file named "foo.bar", and you try to search for files ending in .bar, then doing a:

   find . -name *.bar

may return just "./foo.bar" as the shell expanded *.bar to foo.bar, and passed that to find.

To fix, wrap arguments you pass to find in quotes if they contain wildcard characters.

(edit: fixed formatting as HN uses asteriks to italicize)

Escaping the asterisk also works.

  find . -name \*.bar

Also passes the unexpanded argument "*.bar" to find.

While find still shines for finding files on metadata, I wrote a script elaborating on the 'du -a | grep "search term"' from Kernighan and Pike's The Unix Programming Environment. In many ways it does a better job of finding files by name than find does.

du -a | grep -y "$1" | grep -y "$2" | awk '{print $2}'

I am planning to rewrite to handle more than two search terms, but it works for me good enough for now.

> In many ways it does a better job of finding files by name than find does.

Your du command is:

    du -a | grep -y "$1" | grep -y "$2" | awk '{print $2}'

The find command I would use for the same effect is:

    find -iregex ".*$1.*" -a -iregex ".*$2.*"

How does the du command do a better job than the find command?

Unless find has been changed since the last time I tangled with it; you need to explicitly put the search path in first (which yours doesn't do), which since that is opposite the utilities I used more often, I kept forgetting to. Second, find seems to react weirdly to wildcards in search terms, I sometimes ended up rerunning it with slightly different search terms to be find the file I wanted.

Maybe I just wasn't using find right, but several introductory linux books have also claimed it is hard to use. Before I found the du -a | grep idea, I was using one I read somewhere else of grepping a directory listing (made by ls -lR ~/ > dir) rather than use find.

The man page says that if path is omitted in

    find [path...] [expression]

the current directory is used. I don't know if it's just that way for GNU find, or if it's standard Posix find behaviour.

Regarding the wildcards in search statements, I usually just need to match a case-sensitive substring, so I use something like:

    find -name '*sub*'

I don't know of any weird wildcard reactions, but that may be because I don't usually use complex searches or matches.

One last thing, if you don't mind all the "./" prefixes, "find ." (or just "find") is just like "du -a" without the block counts.

Reply on news.ycombinator.com