为了计算开放的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用于测试，但无法使其工作。以最简单的形式说明潜在的问题：
有2个文件，/test.epub＆amp; /test.fb2在fbreader中以单独的窗口，bash，lxterminal，在Ubuntu 14.04 LTS和普通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不应该受到指责），但为什么{{1} } snub lsof个文件？
================== 附：我编辑了这篇文章，把它放在适当的上下文中，尽管由于Mr.Hyde，它已经解决了。所陈述的问题反映了隐含和未经审查的假设，结果证明是错误的。见答案。
答案 0 :(得分：1)
海德的评论是我需要的线索。所以他应该得到信用。我不清楚它是如何工作的，但是我已经潜伏到这个网站足以知道它对你们都很重要。
所以，对，如果fbreader保持一个文件打开但不保持另一个，正如Hyde建议的那样，问题就是原因。我假设文件类型是重要的，但是一旦我以这种方式看待它的可能性很明显，我测试了它，问题不是类型而是文件大小。我只找到一个fb2来测试我的脚本，它恰好比我的大多数epub都要小。我发现了一个小epub，它的行为方式相同。据推测，如果文件足够小，那么fbreader只会将整个内容存储在memeory中，但不能存储更大的文件。所以，mea culpa，所述问题是虚假的。脚本pov的底线是我需要使用的 ps -eo args 代替 lsof的 因为ps将文件视为启动打开进程而不是打开文件的命令的参数，而且无论如何这可能更重要。谢谢，绅士。