lsof，grepping输出

Question

为了计算开放的epubs，我使用了这个：

# - 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进行测试，但无法使其工作。为了用最简单的形式来说明潜在的问题：

有两个文件，/test.epub和/test.fb2在fbreader中打开，在单独的窗口中，在bash中，在LTS终端中，在Ubuntu14.04LTS和纯Openbox下打开

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文件呢？

==================附言:我对这篇文章进行了编辑，把它放在适当的上下文中，尽管多亏了Mr.Hyde，它已经被解决了。如上所述，这个问题反映了一个隐含的、未经检验的假设，事实证明这是错误的。请参见答案。

Answer 1

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

所以，对了，如果fbreader像海德建议的那样，让一个文件保持打开状态，而不是另一个文件，那么问题就是为什么。我假设文件类型是最重要的，但一旦我这样看它，可能性是显而易见的，我测试了它，问题不是类型，而是文件大小。我只找到了一个fb2来测试我的脚本，而且它碰巧比我的大多数epub都小。我找到了一个小epub，它的行为也是一样的。大概如果文件足够小，fbreader只会将整个文件存储在内存中，而不能存储更大的文件。所以，我错了，这个问题是假的。脚本pov的底线是我需要使用ps -eo args而不是lsof，因为ps将该文件视为启动打开进程的命令的参数，而不是打开的文件，这可能更切中要害。谢谢，先生们。