每当我使用readdir之类的函数列出目录的内容时，返回的文件名也包含“。”。和“......”。我怀疑这些只是文件系统中的普通链接，因此与实际文件无法区分，但我总是要将它们过滤掉，因为它们不是我列出的目录中的实际对象。 readdir这样的函数是否有充分理由包含它们？某些操作系统或文件系统是否包含更多或不同的虚拟文件名？除了通过与“。”进行字符串比较之外，还有更好的方法来过滤掉它们。和“..”？
更新：谢谢大家回答。我想我一直认为像./和../之类的东西仅仅是可以通过搜索和替换来处理的约定。我觉得让它们成为文件系统本身的一部分有点令人惊讶，尽管可能更有效和透明。
但仍存在一个问题：自此。和..是这些链接的任意名称，是否有使用不同文件系统的文件系统？
答案 0 :(得分：11)
.和..实际上是文件系统中的硬链接。它们是必需的，以便您可以根据某些参考路径指定相对路径（考虑"../sibling/file.txt"）。由于这些硬链接实际存在于文件系统中，因此readdir告诉您它们是有意义的。 （实际上，术语hard link只是意味着某些名称与所引用的实际目录无法区分：它们都指向文件系统中的相同inode。
如果你不想列出它们，最好的方法就是strcmp并忽略它们。
答案 1 :(得分：6)
最初它们是硬链接，以及文件系统代码中的特殊情况数。而且......很小。然而，对于所有现代文件系统而言，情况并非如此。
但是已经建立了约定，即使这两个目录条目实际上不存在的文件系统仍然通过readdir等API报告它们的存在。改变这种情况现在会破坏很多代码。
答案 2 :(得分：3)
一个原因是没有它们就无法进入父目录。或者获取当前目录的句柄。
没有他们，我们不能做以下事情：
./run_this
确实，我们无法添加'。'到$ PATH，意味着我们不能执行那些尚未在路径中的文件。
答案 3 :(得分：3)
我怀疑这些是 只是文件系统中的普通链接 因此无法区分 实际文件
他们是。虽然您可能将文件系统视为“包含”文件夹的“文件夹”层次结构，但它实际上是一个双重链接的树 1 ，目录是节点，文件是叶子。因此，.和..是访问当前节点的叶子和遍历树所需的链接，它们与所有其他链接是相同的。
当您致电readdir时，您将获得可以从当前节点直接转到的所有地点。如果您不想列出您认为“向上”的地方，则必须自己对其进行排序。您应该为此编写一个小函数，可能称为readdir_down。我不知道readdir列出目录的顺序，但也许你可以扔掉前两个条目。
1 ）这是第一个近似值，也有可能使树实际成为网络的“硬链接”。
答案 4 :(得分：1)
这些是普通目录，它们是上面当前目录和目录的“硬链接”。它们存在于所有目录中（即使在根级别，..与.完全相同）。
使用ls时，您可以使用.过滤掉..和ls -A（请注意首都-A）。
将命令应用于所有点文件，但不是.或..时，我经常使用.??*，它只匹配点名为3个字符或更多的点文件。
touch .??*
请注意，此模式还会排除以dot开头并且只有两个字符长的任何其他文件（例如.x），但这些文件并不常见。
使用readdir()等程序化文件夹时，我必须手动排除.和..。由于这两个文件应该是readdir()返回的列表中的第一个，因此您可以这样做：
@files = readdir(DIR);
for (1..2) { shift @files; } # get rid of . and ..
# go on with your business
答案 5 :(得分：0)
报告它们是因为它们存储在目录列表中。这就是unices一直有效的方式。
答案 6 :(得分：0)
因为在类Unix操作系统上，目录列表命令包含这些命令，您可以使用它们在文件系统层次结构中上下移动。
像grep { not /^.{1,2}\z/ } readdir HANDLE这样的东西应该适合你。
答案 7 :(得分：-4)
目录扫描应该返回这些文件名是没有充分理由的。