如果我跑 ls -a
user@users-MacBook-Pro:~$ ls -a
. ..
我得到.和..（当前目录和父目录？）
他们出现之后有什么原因吗ls -a，他们做了什么有趣的事情吗？
ctr*_*lor 66
因为-a意味着显示所有文件。与 结合使用时很有用-l。至于为什么在不使用时显示那些无用的文件-l，因为一致性，并且因为 Unix 不会试图重复猜测什么对您有好处。
有一个选项-A（至少对于 GNU 而言ls）可以排除这两个（.., 和.）。
有趣的是，Unix 中隐藏文件的想法是由于ls它试图隐藏这两个文件的错误而产生的。为了使代码简单，原始实现只检查第一个字符。人们用它来隐藏文件，然后它变成了一个功能，并且-a添加了显示隐藏文件的选项。后来有人想知道，和你一样，为什么 .和..显示出来，我们知道他们在那里。该-A选项诞生了。
注意：Unix 对文件的含义比您可能拥有的含义要宽松得多。
文件 ？{普通文件、目录、命名管道、unix-socket、符号链接、设备}。
Aar*_*sco 43
他们出现在那里有什么意义吗？
它们显示所有权和权限。当您有两个用户并且一个用户说他们无法看到他们期望看到的另一个人的文件时，这通常是要检查的最重要的事情。
如https://ss64.com/bash/ls.html 中所示， 当您向您添加-a参数时，您将ls
获得所有条目，甚至以.;开头的条目。它们被视为隐藏条目，不会以简单的ls.
他们出现之后有什么原因
ls -a吗？
我敢打赌，这只是一个历史事故，就像很多事情一样。
根据Rob Pike的故事，“隐藏”文件（dotfiles）是由意外创建的：
很久以前，随着 Unix 文件系统的设计被制定出来，条目
.和..出现，使导航更容易。我不确定，但我相信..在版本 2 重写期间进入，当时文件系统变得分层（它早期具有非常不同的结构）。ls然而，当输入时，这些文件就会出现，因此 Ken 或 Dennis 向程序添加了一个简单的测试。当时是在汇编程序中，但有问题的代码相当于这样的：Run Code Online (Sandbox Code Playgroud)if (name[0] == '.') continue;这个声明比它应该的要短一点，那就是
Run Code Online (Sandbox Code Playgroud)if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;但是，嘿，这很容易。
结果有两件事。
[...]其次，更糟糕的是，创建了“隐藏”或“点”文件的想法。结果，更多懒惰的程序员开始将文件放入每个人的主目录中。
基于此，猜测ls -a添加然后显示那些懒惰的程序员创建的点文件似乎并不牵强。对此的简单实现只是依次禁用上述测试，从而再次显示.并..显示。
不管历史如何，现在显示它们是标准中指定的行为：
-a
写出所有目录条目，包括名称以 <句号> ( '.' ) 开头的条目。
但也有ls -A做稍微理智的事情。我不知道那个比它更新多少：
-A
写出所有目录条目，包括名称以 <句号> ( '.' ) 开头的条目，但不包括条目 dot 和 dot-dot（如果存在）。
他们会做一些有趣的事情吗？
用plain 列出它们ls并不是很有趣。
但是查找 eg .in/path/subdir给出的 inode 与查找subdirin相同/path。目录的所有权和权限控制谁可以访问那里的文件，因此这些信息也可以通过 获得.。然而，人们总是可以做到ls -ld .或者ls -ld /path/subdir，如果他们需要的目录本身的属性。
此ls选项需要显示所有文件ls -a...
但实际存在.，并..在大多数文件系统是从上世纪70年代制造品，当电脑已经非常微小的，人们试图发现只需要少量的代码大小实现。这导致了到当前目录和父目录的硬链接。
30 多年来，这被视为一个错误。
事实上，UNOS（1980 年的第一个 UNIX 克隆）没有.和..，我的 WOFS（写文件系统上的第一个副本）和 ZFS 也没有它们。
当传递给处理文件名的系统调用时，POSIX 所需要的只是处理dir/.和dir/..预期的方式。
不幸的是，今天的大多数软件仍然写得很糟糕，并且在缺少这些条目时会出现问题，这就是 ZFS 模拟存在的原因....
因此，未指定是否ls -a为.和打印行..。这取决于文件系统。如果您使用的文件系统不包含物理条目.并且..不假装拥有它们（如 ZFS），则需要调用：ls -ld . ..
顺便说一句：POSIX 最近决定echo .*不再需要包含.and ..，即使它们实际存在。一旦所有炮弹都以这种方式运行，这将是一个巨大的胜利。