☰

目录中的“。”和“..”有什么问题？

tag-icon • tag-icon command-line
目录中的“。”和“..”有什么问题？

当我使用 nautilus 浏览目录时（此目录中的具体示例是 /media 文件夹）我什么也看不到，但是当我ls -a在终端中输入时它会显示：

. 
..

用蓝色表示。我知道蓝色高亮部分是目录，而.和..可以表示父目录和工作目录，但是为什么它们在/media文件夹中呢？

答案1

如果 Nautilus 不显示任何内容而ls -a仅显示.和..，则该目录中没有任何内容。

Directory.表示当前目录，它是一种使用相对路径引用文件和目录的方式。例如./subdir1/subdir2/somefile

当你发出命令时ls，它会被翻译成ls .

也是一样..，它是一种引用父目录的方式。例如../../etc/cron.d。

答案2

这两个条目是您机器上的文件系统不可或缺的组成部分，并且存在于内核的低级目录列表函数返回的列表中。

正如其他人所说，..是指向父目录的链接，并且.是指向当前目录的链接。

一些前端（例如 nautilus）隐藏了这两个条目，因为它们在图形环境中实际上并不那么相关，但它们仍然存在。

它们为什么存在？

这些是方便快捷方式。它们在整个文件系统中实现，以确保无论您使用哪个应用程序，它们都能正常工作 - 它们不依赖于单个应用程序的支持。它们可以在允许目录路径的任何地方工作，包括配置文件。

  • 快捷方式..允许您使用 来引用目录的父目录directory/..，使用 来引用目录的祖父目录directory/../..，等等。

  • 快捷方式.允许您明确引用当前目录，以防应用程序需要您指定要搜索的目录（或多个目录），并且您想要在当前目录中搜索。

    例如，.可以添加到PATH环境变量中，允许默认在当前目录中搜索匹配的可执行文件。或者，如果不存在PATH，您可以使用./myscript在当前目录中运行脚本，即使PATH环境变量不会在当前目录中查找可执行文件。

如何实现

在大多数传统文件系统中，.和..条目在磁盘上实现为目录条目，它们共享一个索引节点它们指向的目录 - 也就是说，它们就像硬链接到当前目录和父目录，但它们不能被删除或修改。

在操作系统内核的帮助下，该..条目甚至可以跨挂载点工作，从而确保挂载点的根目录将有一个..条目作为挂载所在父目录的链接实现。无论文件系统类型如何，这种情况都会发生 - 即使在虚拟文件系统中也会发生这种情况/proc。

.和..是保留文件名 - 无法创建实际的文件或目录并为其指定.或..作为名称（尽管您可以开始包含这些字符的文件名）。

答案3

存在的原因和.使用..

.并且..是通常存在的条目在每个目录中。它们的含义与进程（如 shell）的工作目录无关，而是与条目所在的目录有关。

..提供目录树结构的双向链接，而 是.用于引用目录本身的方便名称。路径directory/.与 相同directory。理论上可以选择一个空字符串来引用目录本身，但实际上并非如此：ls ''不起作用，并且空字符串的含义不明确，因为在路径的开头它已经引用了根目录：是/file1指file1在根目录中还是file1在当前工作目录中？

正如 thomasrutter 所展示的，重要的是，您可以将.和用作..路径中的普通目录条目。例如，./-filename可用于避免将破折号字符解释为命令行选项的介绍。实际-路径与 相同，与 相同。directory1/../directory2./directory2directory2

为什么.和..被隐藏了？

.以开头的文件（和目录）名称在类 Unix 系统中按照惯例是隐藏的，因此默认情况下大多数工具不会显示.和..目录。这很有用，因为我们已经知道.和..通常存在于每个目录中。

该命令ls -a显示所有目录条目。在 Nautilus 中，Ctrl+H会显示隐藏条目，但 和 除外.，..因为它们在图形文件管理器中通常不太有用。要在命令行上获得类似的行为，您可以使用ls -A。

是真实的目录条目吗.？..

是的，在常用的文件系统中它们确实存在。（正如 Jonathan Leffler 提醒的那样）我们如何检查呢？

# prepare the directory
cd /tmp ; mkdir testdir1

# test 1
ls -lid testdir1 testdir1/. testdir1/..
1179767 drwxrwxr-x  2 pabouk  pabouk  4096 Nov 12 11:52 testdir1
1179767 drwxrwxr-x  2 pabouk  pabouk  4096 Nov 12 11:52 testdir1/.
1179650 drwxrwxrwt 14 root    root    4096 Nov 12 15:17 testdir1/..

testdir1指向目录/文件本身数据结构的 inode 编号（第 1 列）对于同一个目录和是相同的testdir1/.。链接计数（第 3 列）显示指向 inode（目录/文件）的目录条目数，在创建目录后立即为 2，因为testdir1和/tmp中.有。 （ ）/tmp/testdir1的 inode有 14 个链接，因为它有 12 个子目录，每个目录都包含+ 2 个条目。/tmp/testdir1/../tmp..

# test 2
touch testdir1/tesfile1   # to have a regular file too

debugfs /dev/sda2 -R 'ls -l /tmp/testdir1' | cat
debugfs 1.42.12 (29-Aug-2014)
 1179767   40775 (2)   1000   1000    4096 12-Nov-2015 11:52 .
 1179650   41777 (2)      0      0    4096 12-Nov-2015 15:46 ..
 1179771  100664 (1)   1000   1000       0 12-Nov-2015 11:52 tesfile1

该实用程序debugfs直接从磁盘扇区读取 ext2（及更新版本）文件系统数据（绕过 Linux 内核中的文件系统）。

# test 3

debugfs /dev/sda2 -R 'dump /tmp/testdir1 '>(od -tax1)
debugfs 1.42.12 (29-Aug-2014)
0000000   w nul dc2 nul  ff nul soh stx   . nul nul nul stx nul dc2 nul
         77  00  12  00  0c  00  01  02  2e  00  00  00  02  00  12  00
0000020  ff nul stx stx   .   . nul nul   { nul dc2 nul   h  si  bs soh
         0c  00  02  02  2e  2e  00  00  7b  00  12  00  e8  0f  08  01
0000040   t   e   s   f   i   l   e   1   s   o   c   k   e   t nul nul
         74  65  73  66  69  6c  65  31  73  6f  63  6b  65  74  00  00
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
         00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
*
0010000

如果您不相信目录列表，debugfs您可以检查目录的原始转储并检查.和..条目是否确实存在。

答案4

.是当前目录，..是父目录。以以下目录层次结构为例：

foo
└── bar

foo/.和foo/bar/..是foo。

相关内容