目录中的项目是否有通用术语？

POSIXreaddir文档使用单词entry：

readdir()函数应返回一个指向结构的指针，该结构表示目录流中由参数 dirp 指定的当前位置的目录条目，并将目录流定位在下一个条目处。它应在到达目录流的末尾时返回一个空指针。<dirent.h>标头中定义的结构dirent描述了目录条目。

文件。至少在 POSIX 兼容的系统中。

3.164文件

可以写入或读取或两者兼而有之的对象。文件具有某些属性，包括访问权限和类型。文件类型包括常规文件、字符特殊文件、块特殊文件、FIFO特殊文件、符号链接、套接字和目录。实现可能支持其他类型的文件。

^（来源）

当人们仅指“常规文件”时说“文件”并不真正符合 POSIX。:)

您可以从这个问题的答案中了解什么是 POSIX 。各种操作系统是否符合 POSIX（完全或大部分）。无需详细说明，此答案适用于 Unix 和类 Unix 系统（包括 macOS、Linux、BSD），但不适用于一般的 Windows 系列。

好问题。

我使用“内容”作为包含文件和子文件夹的术语。

例如：“我们需要复制该目录的所有内容。”

有建议文件和条目的好答案。（如果您不明白为什么这些词合适，请阅读它们，并记住在 POSIX 中“文件”包括所有类型的索引节点（包括目录），而不仅仅是常规文件）。 目录条目（文件名）是对文件/索引节点的引用。

一个文件在不同的目录中可以有多个名称（链接数 > 1）。实际的文件数据/inode 不存储在包含它的文件名的目录中。

但是理智的人说“读取某个目录中的文件”之类的话没有问题。总是费心区分文件（inode + 数据）和引用它的文件名/目录条目是不必要的迂腐。

另请注意，现代文件系统中的目录条目通常还存储一个“类型”字段，因此程序find不需要stat(2)每个文件来检查谓词，如find -type f（常规文件）与符号链接或其他东西。或者在递归时查找本身就是目录的条目。请参阅检查目录是否存在。readdir 返回的条目是目录、链接或文件。dent->d_type 未在 Stack Overflow 上显示类型。

“路径”如foo/bar或/a/b/foo/bar是以文件名结尾的字符串，但可以使用目录来引用不在当前目录中的文件名。 foo是一个简单的路径，也是一个文件名。但是foo/bar是文件名，也是路径。但是你可以争论它不是“文件名”的语义。路径或路径名是您可以传递给 POSIX 或 Win32 等系统调用open(2)的chdir(2)内容OpenFile()

您对术语的选择（文件与文件名与目录条目）可能取决于上下文和您正在做的事情。例如，读取内容或 inode 元数据涉及实际文件。

但是仅仅将 glob 表达式与名称匹配根本不涉及文件，只涉及文件名/目录条目。

目录条目在实际循环函数（如 ）时最合适readdir(3)，或者例如“用于ln创建引用此文件的新目录条目”。在处理硬链接时，术语“dir entry”有别于文件，而不是“文件名”。

但是“名字”也可以。例如“具有 2 个名称的文件”。

更常见的是，您会使用诸如c_files=( *.c ). Or fn（对于文件名）也是一个很好的本地使用变量名。

使用起来entries=( *.c )会感觉怪怪的。“条目”只有在谈论循环遍历它们以获取文件名的过程时才感觉正确，而不是针对与某些过滤器匹配的结果文件名集。

为什么不提高抽象级别而不仅仅是使用“计算机术语”：
加强更通用的措辞......

成熟的文件系统存储content.

它允许“文件”和“文件夹”作为基本内容。
大多数情况下，“文件夹”可能会存储内容的子级别......

根据文件系统的选择，可能会有其他内容类型。

我喜欢树这个术语，事实上在 Linux 中有一个命令tree，它列出了当前目录和下面所有目录中的所有内容以及它们的文件和子目录。

以下是安装和使用该tree命令的示例。来自链接的示例：

虽然终端截图一般不被看好，但纯文本的复制粘贴比较受青睐，我想这种违规行为应该会得到大多数读者的谅解。