“ln”和“ln -s”的行为看似不一致

Question 1

阅读你的手册页：问题 1 = 第一种形式，这是因为在 Linux 中所有项目都被视为文件，甚至是目录。例如，使用文本编辑器“打开”/etc/，即： nano -w /etc/ nano 会礼貌地告诉您 /etc/ 是一个目录，因为创建永无止境的符号链接在技术上是合法的。过去，在编写边界检查之前，我可以拥有一个 FHS 系统，其中有 2 个名为 /etc 的文件，一个是文件，一个是目录，并且系统知道其中的区别

（见哈哈注释Chromiumos 开发者指南:

有一个文件系统循环，因为在 ~/trunk 中你会再次找到 chroot。不要想这个问题太久。如果您尝试使用 du -s ${HOME}/chromiumos/chroot/home 您可能会收到有关文件系统损坏的消息。这没什么好担心的，只是意味着你的计算机也不理解这个循环。（如果你能理解这个循环，请尝试更难的事情。

我敢，请点击更难的东西:) 为了防止循环 ln 需要完整路径。

问题2可以通过再次阅读man page来回答看最后一句：

描述

   In the 1st form, create a link to TARGET with the name LINK_NAME.  In
   the 2nd form, create a link to TARGET in the current directory.  In
   the 3rd and 4th forms, create links to each TARGET in DIRECTORY.
   Create hard links by default, symbolic links with --symbolic.  By
   default, each destination (name of new link) should not already
   exist.  When creating hard links, each TARGET must exist.  Symbolic
   links can hold arbitrary text; if later resolved, a relative link is
   interpreted in relation to its parent directory.

回复：编辑：“但是，为什么当您运行命令时 shell 无法解析该路径，而不是强迫用户找出路径是什么并自己输入它？”

考虑以下示例：应用程序 A 安装库版本 1.0.a。您构建依赖于库 A 的应用程序 X、Y、Z。应用程序 A 发现错误，对其进行更新并将库另存为 1.0.1.2.a。由于应用程序 X、Y 和 Z 仍然使用库 1.0，如果我直接用 1.0.1.2 替换 1.0，则会出现损坏，但如果我将版本 1.0.1.2 符号链接到版本 1.0，则不会出现任何损坏，

ln -s /usr/lib64/libfoo-1.0.1.2.a /usr/lib64/libfoo-1.0.a

应用程序 X、Y 和 Z 也从应用到它们的库中获取新的错误修复，因为 shell 遵循从 1.0 到 1.0.1.2 的链接，但将其称为 1.0。在这种情况下，您不希望 shell 假定该路径，因为这会增加系统范围内损坏的机会。顺便说一句，64 位系统上的 /usr/lib 链接到 /usr/lib64，以纠正我刚刚给出的大规模示例，即 32 位应用程序期望库安装在 /usr/lib 上，而在 64 位系统上系统没有纯 32 位库，因此 /usr/lib 链接到 /usr/lib64，如下所示：

ln -s /usr/lib64 /usr/lib

Answer

阅读你的手册页：问题 1 = 第一种形式，这是因为在 Linux 中所有项目都被视为文件，甚至是目录。例如，使用文本编辑器“打开”/etc/，即： nano -w /etc/ nano 会礼貌地告诉您 /etc/ 是一个目录，因为创建永无止境的符号链接在技术上是合法的。过去，在编写边界检查之前，我可以拥有一个 FHS 系统，其中有 2 个名为 /etc 的文件，一个是文件，一个是目录，并且系统知道其中的区别

（见哈哈注释Chromiumos 开发者指南:

有一个文件系统循环，因为在 ~/trunk 中你会再次找到 chroot。不要想这个问题太久。如果您尝试使用 du -s ${HOME}/chromiumos/chroot/home 您可能会收到有关文件系统损坏的消息。这没什么好担心的，只是意味着你的计算机也不理解这个循环。（如果你能理解这个循环，请尝试更难的事情。

我敢，请点击更难的东西:) 为了防止循环 ln 需要完整路径。

问题2可以通过再次阅读man page来回答看最后一句：

描述

   In the 1st form, create a link to TARGET with the name LINK_NAME.  In
   the 2nd form, create a link to TARGET in the current directory.  In
   the 3rd and 4th forms, create links to each TARGET in DIRECTORY.
   Create hard links by default, symbolic links with --symbolic.  By
   default, each destination (name of new link) should not already
   exist.  When creating hard links, each TARGET must exist.  Symbolic
   links can hold arbitrary text; if later resolved, a relative link is
   interpreted in relation to its parent directory.

回复：编辑：“但是，为什么当您运行命令时 shell 无法解析该路径，而不是强迫用户找出路径是什么并自己输入它？”

考虑以下示例：应用程序 A 安装库版本 1.0.a。您构建依赖于库 A 的应用程序 X、Y、Z。应用程序 A 发现错误，对其进行更新并将库另存为 1.0.1.2.a。由于应用程序 X、Y 和 Z 仍然使用库 1.0，如果我直接用 1.0.1.2 替换 1.0，则会出现损坏，但如果我将版本 1.0.1.2 符号链接到版本 1.0，则不会出现任何损坏，

ln -s /usr/lib64/libfoo-1.0.1.2.a /usr/lib64/libfoo-1.0.a

应用程序 X、Y 和 Z 也从应用到它们的库中获取新的错误修复，因为 shell 遵循从 1.0 到 1.0.1.2 的链接，但将其称为 1.0。在这种情况下，您不希望 shell 假定该路径，因为这会增加系统范围内损坏的机会。顺便说一句，64 位系统上的 /usr/lib 链接到 /usr/lib64，以纠正我刚刚给出的大规模示例，即 32 位应用程序期望库安装在 /usr/lib 上，而在 64 位系统上系统没有纯 32 位库，因此 /usr/lib 链接到 /usr/lib64，如下所示：

ln -s /usr/lib64 /usr/lib

Question 2

问题1：为什么软链接需要写出两个文件/文件夹的整个路径，而硬链接可以省略目标文件的文件名？

您也不需要指定软链接的路径或文件名，除非目标位于当前目录中。例如，如果您有一个文件~/Downloads/target_file，您可以执行以下操作：

ln `~/Downloads/target_file`

当你在时~/，这将创建硬链接添加文件名，你也可以这样~/Downloads/target_file做~/target_file

ln -s `~/Downloads/target_file`

当你在时~/，这将创建软链接与文件名~/Downloads/target_file一起输入。~/target_file

问题2：为什么软链接的OLD文件/文件夹的文件路径是相对于其父级的，而其他3个路径（硬链接OLD、NEW文件、软链接NEW文件/文件夹）是相对于文件/文件夹的他们自己？

所有四个路径都可以是相对路径（相对于当前文件夹）以及绝对路径；唯一的标准是，如果您未指定名称或路径，则硬链接或软链接不应位于同一文件夹中。

你应该阅读ln 的手册页。已在 Ubuntu 14.04 上尝试过所有这些，但仍然通过手册页进行了确认，因此您无需担心操作系统；它不是特定于操作系统的。

Answer