最小的解决方案是添加可读标志。

找到。-name foo -readable

Use:

find . 2>/dev/null > files_and_folders

当然，这不仅隐藏了Permission denied错误，还隐藏了所有错误消息。

如果你真的想保留其他可能的错误，比如符号链接上的跳数太多，而不是权限被拒绝的那些，那么你可能不得不大胆猜测你没有很多被称为“权限被拒绝”的文件，然后尝试:

find . 2>&1 | grep -v 'Permission denied' > files_and_folders

如果你只想过滤标准误差，你可以使用更精细的结构:

find . 2>&1 > files_and_folders | grep -v 'Permission denied' >&2

The I/O redirection on the find command is: 2>&1 > files_and_folders |. The pipe redirects standard output to the grep command and is applied first. The 2>&1 sends standard error to the same place as standard output (the pipe). The > files_and_folders sends standard output (but not standard error) to a file. The net result is that messages written to standard error are sent down the pipe and the regular output of find is written to the file. The grep filters the standard output (you can decide how selective you want it to be, and may have to change the spelling depending on locale and O/S) and the final >&2 means that the surviving error messages (written to standard output) go to standard error once more. The final redirection could be regarded as optional at the terminal, but would be a very good idea to use it in a script so that error messages appear on standard error.

这个主题有无穷无尽的变化，取决于你想做什么。这将在任何带有任何Bourne shell衍生物(Bash, Korn，…)的Unix变体和任何posix兼容版本的find上工作。

如果您希望适应系统上的find的特定版本，可能有可用的替代选项。特别是GNU find有许多其他版本没有的选项-请参阅当前接受的一组选项的答案。

重定向标准错误。例如，如果你在unix机器上使用bash，你可以像这样将标准错误重定向到/dev/null:

find . 2>/dev/null >files_and_folders

通过使用2>/dev/null管道stderr到/dev/null

找到。- name”……2 > / dev / null

这些错误被打印到标准错误输出(fd 2)。要过滤它们，只需将所有错误重定向到/dev/null:

find . 2>/dev/null > some_file

或者首先连接stderr和stdout，然后grep出那些特定的错误:

find . 2>&1 | grep -v 'Permission denied' > some_file

上面的答案对我都没用。我在网上找到的东西都集中在:隐藏错误。没有正确处理进程返回码/退出码。我在bash脚本中使用命令find来定位一些目录，然后检查它们的内容。我计算命令查找成功使用退出代码:值为零工作，否则失败。

Michael Brux提供的答案有时是有效的。但我有一个失败的场景!我发现了问题，自己解决了。我需要修剪文件时:

it is a directory AND has no read access AND/OR has no execute access

这里的关键问题是:AND/OR。我读到的一个很好的建议条件序列是:

-type d ! -readable ! -executable -prune

这并不总是有效的。这意味着当匹配为:

it is directory AND no read access AND no execute access

当授予读访问权限而不授予执行访问权限时，此表达式序列将失败。

经过一些测试后，我意识到这一点，并将我的shell脚本解决方案更改为:

find /home*/ -maxdepth 5 -follow \ \(type d -a !\(-readable -a -executable \) \) -删除\ - o \ \(-type d -a -readable -a -executable -name "${m_find_name}" \) -打印

这里的关键是在组合表达式中放置“not true”:

has read access AND has execute access

否则它没有完全访问权限，这意味着:修剪它。事实证明，在一个之前建议的解决方案失败的场景中，这对我来说是有效的。

我在评论部分提供了以下技术细节。如果细节过多，我很抱歉。

¿Why using command nice? I got the idea here. Initially I thought it would be nice to reduce process priority when looking an entire filesystem. I realized it makes no sense to me, as my script is limited to few directories. I reduced -maxdepth to 3. ¿Why search within /home*/? This it not relevant for this thread. I install all applications by hand via source code compile with non privileged users (not root). They are installed within "/home". I can have multiple binaries and versions living together. I need to locate all directories, inspect and backup in a master-slave fashion. I can have more than one "/home" (several disks running within a dedicated server). ¿Why using -follow? Users might create symbolic links to directories. It's usefulness depends, I need to keep record of the absolute paths found.