find / -name netcdf


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

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


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

  • 1
    I do not like throwing out warnings. It is much better to handle them. Also, no escaping here in the field. – Léo Léopold Hertz 준영 Jul 4 '16 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... – chrips Jul 16 '19 at 5:14

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

  • 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. – vonbrand Mar 23 '14 at 15:41
  • 4
    @vonbrand it's necessary if you rely on find's exit status, because these permission errors make find exit with non-zero status – Ernest A Mar 24 '15 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. – Léo Léopold Hertz 준영 Jul 4 '16 at 15:55
  • 2
    Wow, I can't believe it was so hard to find this answer, I now wish I could do more than just upvote it. – Wedge Nov 8 '17 at 0:20

Use locate(1) instead:

$ locate netcdf

It will only show you files your user can see.

  • 1
    This assumes that updatedb is running regularly. That is not the case on all Linux systems. – Arcege Aug 26 '11 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). – Warren Young Aug 26 '11 at 3:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.