lsof，[关闭]的grepping输出答案

【问题标题】：lsof, grepping output of [closed]lsof，[关闭]的grepping输出
【发布时间】：2016-01-04 04:47:41
【问题描述】：

为了计算打开的 epub，我使用了这个：

# - determine how many epubs are open -
NUMBER_OF_OPEN_EPUBS=0
while read -r LINE ; do
    if [ "$(echo $LINE | rev | cut -c1-5 | rev)" = ".epub" ]; then
        NUMBER_OF_OPEN_EPUBS="$(($NUMBER_OF_OPEN_EPUBS+1))"
    fi
done < <(lsof | grep "\.epub")
# --- end determine how many epubs are open ---

它总是有效的。但我也想将它扩展到 fb2 文件（类似于 epubs），所以我得到了一个 fb2 用于测试，但无法使其工作。以最简单的形式说明根本问题：

有 2 个文件，/test.epub 和 /test.fb2 在单独的窗口、bash、lxterminal、Ubuntu 14.04 LTS 和普通 Openbox 下在 fbreader 中打开：

me@nu:~$ lsof | grep "\.fb2" | tr -s " "
me@nu:~$ lsof | grep "\.epub" | tr -s " "
fbreader 28982 me 12r REG 8,5 346340 8375 /test.epub
me@nu:~$

为什么lsof 看不到fb2？实际上，我想我可以使用ps，它对fb2 文件没有偏见（顺便证明grep 不是罪魁祸首），但为什么lsof 冷落fb2 文件？

================== 附言我对此进行了编辑以将其置于适当的上下文中，尽管感谢海德先生，它已经解决了。所陈述的问题反映了一个隐含的未经检验的假设，结果证明是错误的。查看答案。

【问题讨论】：

您的意思是/test.fb2 而不是/test.fbw？
是的。哦。我看了几眼才明白你的意思。如果我能弄清楚如何编辑它，那就更小了。
@Steven。确实，感谢您了解这一点。我可以为此给你布朗尼积分吗？我纠正了这一点，还纠正了一个语法错误。就像您在评论中所做的那样，有人建议突出显示文件和程序名称，所以我接受了这一点，尽管我很好奇为什么这是习惯。
这可能是因为您的应用程序处理文件的方式。也就是说，它不会使其他文件保持打开状态。
然而，这看起来不像是编程问题，所以这里是题外话。如果是关于编程，也许你可以解释你想要做什么。否则，其他一些 SE 网站会更好。

标签： bash grep lsof

【解决方案1】：

海德的评论是我需要的线索。所以他应该得到荣誉。我还不清楚它是如何工作的，但我已经潜伏在这个网站上，知道它对你们很重要。

所以，对了，如果 fbreader 保持打开一个文件而不打开另一个文件，正如 Hyde 所建议的那样，问题就是为什么。我假设文件类型很重要，但是一旦我以这种方式看待它，可能性就很明显了，我对其进行了测试，问题不在于类型，而在于文件大小。我只找到了一个 fb2 来测试我的脚本，而且它恰好比我的大多数 epub 都小。我找到了一个小的 epub，它的行为方式相同。据推测，如果文件足够小，fbreader 只会将整个内容存储在内存中，但不能存储更大的文件。因此，如果过失，上述问题是虚假的。脚本 pov 的底线是我需要使用 ps -eo 参数代替 lsof 因为 ps 将文件视为启动打开进程而不是打开文件的命令的参数，无论如何这可能更重要。谢谢，先生们。

【讨论】：