How to skip "permission denied" errors when running find in Linux?

Question

Possible Duplicate:
How do I remove “permission denied” printout statements from the find program?

When I run this command in Linux (SuSE):

find / -name ant

I get many error messages of the form:

find: `/etc/cups/ssl': Permission denied

Does find take an argument to skip showing these errors and only try files that I have permission to access?

Solution

you can filter out messages to stderr. I prefer to redirect them to stdout like this.

 find / -name art  2>&1 | grep -v "Permission denied"

Explanation:

In short, all regular output goes to standard output (stdout). All error messages to standard error (stderr).

grep usually finds/prints the specified string, the -v inverts this, so it finds/prints every string that doesn't contain "Permission denied". All of your output from the find command, including error messages usually sent to stderr (file descriptor 2) go now to stdout(file descriptor 1) and then get filtered by the grep command.

This assumes you are using the bash/sh shell.

Under tcsh/csh you would use

 find / -name art |& grep ....

Comments

[Admin]

Since you ask about an argument to find, please consider: find / ! -readable -prune. This is like "prune those results not (!) readable". See: stackoverflow.com/questions/762348/…

[Admin]

Yeah! That's a proper way of doing it. And the reason I was searching, Redirecting STDERR should be something nobody should be allowed to ask :P

[rush]

or even just find / -name art 2>/dev/null

[Michael Mrozek]

@rush That would filter out all error messages, not just the permission denied ones

[lornix]

Think about it, that's about all find CAN return as an error message. Disk full, disk read error, ... possible, but rare, and find isn't geared to handle those. You've got OTHER issues if those errors show up anyways. Find's own error result is even vague.. 0=good, !0=something happened. Not even really differentiating anything but pass/fail.

[Levon]

I'm with @MichaelMrozek on this, I would rather see all possible error messages and then decide to filter them out instead of sending them to the bit-bucket unseen.

[Bálint Babics]

When I use find 2>/dev/null I always want only the result set not any other error messages. When a result set returned with null I just run the "regular" find and figure out what the problem is.

[alpha_989]

@Levon, @Michael.. Thank for your answer. The "permission denied" scenario typically happens when you are searching over a lot of directories, such as / where you maynot know or don't want to explicitly chose the directories over whom you have read permissions. If you use pipe operators like in the example.. does find and grep run parallelly, or serially? If its running serially, wont the total execution time be significantly worse (maybe ~50% worse)?

[Mikko Rantalainen]

@alpha_989 in case you didn't already know UNIX-like systems (including Linux and OS X) run the whole pipeline in paraller using multiple CPU cores if available. There's some buffering on the pipeline by default (depending on programs somewhere between 4 KB and 4 MB) but buffering can be disabled if needed (man stdbuf) and then every byte gets delivered immediately.

[ian]

@user3768495 See All about redirection

[Attila]

@rush your solution is safer IMO as it better serves the use-case of re-using the output of find as input for another process: redirecting the stderr to stdout would, despite the grep -v, potentially feed what is at best ireelevant, at worst harmfull data to the next process in the chain.

[Hassan Faghihi]

2>/dev/null filter all errors so I can run -exec ls command too. find / [filters] 2>/dev/null -exec ls -la {} \;