GNU find†的优化解决方案

至少对于某些系统+文件系统组合，find不需要统计文件来获取其类型。然后，您可以在测试可读性之前检查它是否是一个目录，以加快搜索‡-我在测试中获得了约30%的改进。所以对于长时间的搜索或经常运行的搜索，可以使用其中之一:

打印所有可见的东西

$ find . -print -type d ! -readable -prune
$ find . -type d ! -readable -prune , [expression] -print

打印可见文件

$ find . -type d \( ! -readable -prune -o -true \) -o [expression] -print

打印可见目录

$ find . -type d -print ! -readable -prune
$ find . -type d \( ! -readable -prune , [expression] -print \)

只打印可读目录

$ find . -type d ! -readable -prune -o [expression] -print

笔记

†可读的和，(逗号)操作符是GNU扩展。这个表达式

$ find . [expression] , [expression]

逻辑上等价于

$ find . \( [expression] -o -true \) [expression]

‡这是因为启用此优化的查找实现将避免在所讨论的用例中声明非目录文件。

编辑:shell函数

下面是一个POSIX shell函数，我最终将这个测试前置到任何表达式。它似乎可以很好地使用隐式的-print和命令行选项:

findr () {
    j=$#; done=
    while [ $j -gt 0 ]; do
        j=$(($j - 1))
        arg="$1"; shift
        test "$done" || case "$arg" in
            -[A-Z]*) ;;  # skip options
            -*|\(|!)     # find start of expression
                set -- "$@" \( -type d ! -readable -prune -o -true \)
                done=true
                ;;
        esac
        set -- "$@" "$arg"
    done
    find "$@"
}

答案中列出的其他两个替代方案导致POSIX shell中的语法错误(甚至不能源包含函数定义的文件)或ZSH中的糟糕输出…运行时间似乎是相等的。

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

find . 2>/dev/null >files_and_folders

为了在整个文件系统中搜索某些文件，例如主机，除了会导致各种错误的/proc树，我使用以下方法:

# find / -path /proc ! -prune -o -name hosts -type f
/etc/hosts

注意:因为-prune始终为真，所以必须对其求反，以避免在输出中看到行/proc。我试过了!-readable方法，并发现它返回/proc下当前用户可以读取的所有内容。所以"OR"条件并不是你所期望的。

我从find手册页给出的示例开始，参见-prune选项。

我不得不使用:

find / -name expect 2>/dev/null

指定我想要查找的名称，然后告诉它将所有错误重定向到/dev/null

expect是我正在搜索的expect程序的位置。

您可以使用grep -v逆匹配

-v, --invert-match        select non-matching lines

是这样的:

find . > files_and_folders
cat files_and_folders | grep -v "permission denied" > files_and_folders

应该有魔力

上面的答案对我都没用。我在网上找到的东西都集中在:隐藏错误。没有正确处理进程返回码/退出码。我在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.