64

Code

find / -name netcdf 

Output

find: `/root/.dbus': Permission denied find: `/root/.gconf': Permission denied find: `/root/.gconfd': Permission denied find: `/root/.gnome': Permission denied find: `/root/.gnome2': Permission denied find: `/root/.gnome2_private': Permission denied 
1

3 Answers 3

68

Those messages are sent to stderr, and pretty much only those messages are generally seen on that output stream. You can close it or redirect it on the command-line.

$ find / -name netcdf 2>&- 

or

$ find / -name netcdf 2>/dev/null 

Also, if you are going to search the root directory (/), then it is often good to nice the process so find doesn't consume all the resources.

$ nice find / -name netcdf 2>&- 

This decreases the priority of the process allowing other processes more time on the CPU. Of course if nothing else is using the CPU, it doesn't do anything. :) To be technical, the NI value (seen from ps -l) increase the PRI value. Lower PRI values have a higher priority. Compare ps -l with nice ps -l.

2
  • 4
    I do not like throwing out warnings. It is much better to handle them. Also, no escaping here in the field. Commented Jul 4, 2016 at 15:58
  • 1
    @LéoLéopoldHertz준영 WEll... if you can't see program output because yours screen is full of error crap.. which this is the case... Commented Jul 16, 2019 at 5:14
35

I would just like point out this answer by @Gilles in Exclude paths that make find complain about permissions - Unix & Linux Stack Exchange; it basically involves a construct for find that makes it not descend unreadable directories, and in that sense, is probably also a bit faster.

This would seem to work for me:

With GNU find or any other find that supports the -readable and -executable predicates:

find / -type d ! \( -readable -executable \) -prune -o -type f -name netcdf -print 

or also this:

find / -type d ! -perm -g+r,u+r,o+r -prune -o -type f -name 'netcdf' -print 

For some reason, I need to add all of the g+r,u+r,o+r (shortcut for that is a+r), otherwise if one of them is left out, I may still get "Permission Denied" hits.

Here is a breakdown of how I see this (note the -a (and) operator in find is implicit between two predicates):

find / # find starting from path / -type d # match type is directory ! -perm -a+r # (and) match not permissions of `r`ead present -prune # ignore what matched above and do not descend into it -o # or (whatever didn't match above) -type f # match type is file -name 'netcdf' # (and) match name is 'netcdf' -print # print what matched above 

Note that without the last -print, I get some extra items shown (that have nothing to do with -name 'netcdf'); the -print ensures that only the name matches are printed (if any).

5
  • 2
    If find(1) can't descend into a directory, it won't. So checking beforehand if it can or not will just add work (check twice), and thus slow it down. Commented Mar 23, 2014 at 15:41
  • 5
    @vonbrand it's necessary if you rely on find's exit status, because these permission errors make find exit with non-zero status Commented Mar 24, 2015 at 8:47
  • I cannot get your proposal work. I get no output when expected output is full. unix.stackexchange.com/q/290791/16920 However, I think otherwise I think your method is the best way to go. Commented Jul 4, 2016 at 15:55
  • 4
    Wow, I can't believe it was so hard to find this answer, I now wish I could do more than just upvote it. Commented Nov 8, 2017 at 0:20
  • 1
    Note that the -readable way and the -perm way are not equivalent. Commented Mar 25, 2021 at 17:46
13

Use locate(1) instead:

$ locate netcdf 

It will only show you files your user can see.

2
  • 3
    This assumes that updatedb is running regularly. That is not the case on all Linux systems. Commented Aug 26, 2011 at 0:48
  • 5
    If locate(1) is installed, its database should be updated periodically. If that isn't happening, I'd class that a misconfiguration rather than a fault of locate(1). Additionally, it only takes a few minutes to run it by hand in the rare cases where you're looking for a file that was added since the last DB update. I find myself doing that maybe half a dozen times per year, an overhead easily paid for from the speed advantage of locate(1) over find(1). Commented Aug 26, 2011 at 3:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.