查找包管理器未安装的文件

Question 1

您正在寻找的可能是qfile。它是包的一部分app-portage/portage-utils，并提供选项-o或--orphans。你可以使用类似的东西

find /usr/bin -type f | xargs -I{} qfile -o {}

获取中的孤立文件列表/usr/bin。

备注：遗憾的是，qfile在当前稳定版本的 portage-utils 中，不支持从 stdin 读取，并且 qfile 手册页中提到的解决方案qfile -o $(find /usr/bin)在查找结果集很大时不起作用，因此我们必须解决它一点点，使用xargs.

顺便说一句，这不是我自己想出来的，而是我在游丝线程，yvasilev 的评论。

Answer

您正在寻找的可能是qfile。它是包的一部分app-portage/portage-utils，并提供选项-o或--orphans。你可以使用类似的东西

find /usr/bin -type f | xargs -I{} qfile -o {}

获取中的孤立文件列表/usr/bin。

备注：遗憾的是，qfile在当前稳定版本的 portage-utils 中，不支持从 stdin 读取，并且 qfile 手册页中提到的解决方案qfile -o $(find /usr/bin)在查找结果集很大时不起作用，因此我们必须解决它一点点，使用xargs.

顺便说一句，这不是我自己想出来的，而是我在游丝线程，yvasilev 的评论。

Question 2

portage.txt我设法通过运行以下命令来修复与符号链接相关的问题：

equery files '*' | while read i; do readlink -e "${i}"; done | sort | uniq \
       > portage.txt

这用于放入portage.txt符号链接指向的文件，而不是符号链接本身。这是必需的，因为find创建的命令all.txt不会列出任何符号链接，而只是列出它们指向的文件，因此否则会出现很多误报。这是一个相当慢的命令，因为它运行readlink在数千个文件上，但我找不到更好的解决方案。欢迎任何建议。

我理解的另一件事（这更容易）是为什么portage.txt比更大all.txt。这主要是因为我/usr/src从命令结果中明确删除了目录及其下面的所有文件find，但equery无论如何都列出了它们。

我做的最后一件事，即使这不是问题，也是忽略 Python 的东西（主要是文件和带有或后缀的__pycache__文件）：.pyc.pyo

grep '\(\.cpython-32\)\?\.py[co]$\|/__pycache__' candidates.txt \
     > candidates-bytecode.txt
sed -e 's/\(\.cpython-32\)\?\.py[co]$/.py/' \
    -e 's/\/__pycache__//' \
    candidates-bytecode.txt | sort | uniq \
    > candidates-bytecode-source.txt
comm -23 candidates-bytecode-source.txt portage.txt \
     > orphaned-bytecode.txt

通过这种方式，我可以追踪所有 Python 内容的起源并检查它是否在portage.txt.正如您所看到的，我将相同的正则表达式写了两次，一次用于命令grep，另一次用于sed命令，但也许只需一步即可完成。

Answer