Question

将目录路径定义为变量或常量时，是否应以尾部斜杠结尾？惯例是什么？

unix中的

pwd显示当前目录没有尾部斜杠，而cd /var/www/apps/的完整选项卡包含尾部斜杠，这让我不确定。

Answer 1

我使用尾随斜杠，因为：

“如果以斜杠结尾，则为目录。如果不是，则为文件。”是一个容易记住的惯例。
至少在我经常使用的操作系统上，将斜杠加倍会导致没有问题，而省略斜杠会导致大斜杠。因此，最安全的做法是将斜杠放入变量并在使用时使用“$ path / $ file”。

Answer 2

当我例如定义用于存储文件的目录时，我不包括尾部斜杠。那是因为我会像

一样使用它

$store_file = "$store_path/$file_id";

在使用一个应该保存目录路径的变量之前，我总是会添加一个尾部斜杠。我认为总是添加一个比想知道是否包含尾部斜杠更好。

Answer 3

是的，应该如下：

路径名+文件名=完全限定文件位置。

因此，最后一个目录和文件名之间的斜杠需要位于路径名的末尾或文件名的开头。使用/前缀文件名意味着如果您只想打开文件（例如，如果您认为当前工作目录中存在非限定文件名），则需要考虑这一点。

Answer 4

每当我存储目录路径或从API返回它们时，我都会尝试遵循保持尾部斜杠的惯例。这避免了整个'它是文件还是目录'的模糊性。

<强>附录：
这并不是要替代使用能够容忍尾随斜线或不存在斜线的方法。即使使用此约定，我仍然总是使用Path.Combine(...)和类似的方法。

Answer 5

也许您应该考虑一下您的决定对文件意味着什么。如果在目录名称末尾没有包含尾部斜杠，则必须将其添加到文件名称的开头。

现在，如果由于某种原因，在连接字符串时缺少导致文件的路径，那么最终会得到像/filename这样的东西，它不仅仅是一个文件，而是来自根目录的绝对路径（无论在哪里）可能在那种情况下。）

这就是为什么我用斜杠结束我的路径并将文件保存为文件。

Answer 6

我知道这是一个老话题，但我想我会分享我的所作所为。如果可能的话，我通常允许两者并做这样的事情（如果它是PHP）：

$fullPath = rtrim($directory, '/') . '/filename.txt');

这样，如果目录是在配置文件中定义的，那么下一个更改它的人是否包含尾部斜杠并不重要。

Answer 7

在php中，因为dirname（__ FILE __）函数返回目录名而不带斜杠。我倾向于坚持这种惯例。

否则，在目录名末尾使用斜杠会与dirname（..）的工作方式发生冲突，然后由于您不知道目录名是否来自dirname（..）函数或用斜杠定义的符号。

底线：由于dirname（..）没有使用，所以不要使用尾部斜杠。

// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!

对于其他语言，请检查提取路径名的功能，看看它是否使用了斜杠，然后坚持使用语言的约定。

Answer 8

我倾向于只添加尾部斜杠，因为我很可能会使用该目录来添加/检索文件......

就网络参考而言，它实际上可以提高性能，在

中留下尾部斜杠

http://www.netmechanic.com/news/vol4/load_no11.htm

Answer 9

我知道这已经10岁了，但是我想投入我自己的0.02美元。

不。不，绝对不可以

我们正在谈论Unix系统。关于目录本身，它是一个节点，就像其他节点一样。引用目录时，其名称中永远不应带有未转义的斜杠（参考：dirname，pwd，~，echo $HOME，echo $PATH， ls等的输出）。

在引用目录的内容时，然后需要一个斜杠。也就是说，ls /home/karl/比ls /home/karl更合适（FTR，我几乎总是这样做，因为……好吧，懒惰）。

在利用包含目录的变量来创建文件的完整路径时，总是希望包含斜杠（即：cp ${HOME}/test ${OTHER_DIR}/）。

期望目录不能以斜杠结尾。对目录以斜杠结尾的任何期望都是错误的。因此，在*_DIR变量值的末尾添加斜杠将破坏期望。

值得注意的是，仅仅因为它是错误的，并不意味着工具/软件包/库永远都不会这样做。在不存在时，此类事物会在末尾添加斜杠，这是非常常见的情况。因此，正如Bevan和Paul F都建议的那样，在使用第三方工具时，最好删除目录名称中可能存在的任何斜杠。

Unix Inodes

inode（索引节点）是Unix样式的文件系统中的数据结构，用于描述文件系统对象（例如文件或目录）。

-https://en.wikipedia.org/wiki/Inode

文件系统层次结构标准

Unix文件系统的

标准（文件系统层次结构标准，AKA FHS）清楚地表明，目录不被认为带有斜杠，而是目录内容以斜杠开头（唯一例外是/，因为我们不会通过使用空字符串来引用文件系统根...而且无论如何都不应在其中创建文件。）

-http://www.pathname.com/fhs/pub/fhs-2.3.html

-https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Answer 10

是的，有很多文件系统支持没有任何扩展名的文件，因此请始终添加尾部斜杠以避免任何问题。

Answer 11

我从未见过任何坚定的惯例。

但是，很确定，无论你如何解决，其他人都会100％肯定它应该是另一种方式。因此，最好的想法是容忍任何一种方式设置。

在.NET世界中，Path.Combine（）为您提供了一种处理此问题的方法 - 在其他环境中存在等效的文件，从cmd文件开始。

Answer 12

我想这是在少数情况下正确的理论和实践答案都不相同的情况之一。

@Karl Wilbur的回答在理论上似乎肯定是正确的，因为您应该能够将对目录节点本身的引用与目录的内容区分开。

但是在实践中，我认为正确的答案是相反的：

最重要的原因是您可以通过确定性判断路径/home/FSObjectX/是一个文件夹，而/home/FSObjectX是不明确的。没有人知道这是否是一个文件夹文件。
规格应始终准确无误。
在大多数情况下，您始终会引用文件夹的内容，而不是dir节点本身。
在实际情况下，很少会引用代码中的内容通过删除任何可选的尾部目录分隔符。
使用双目录分隔符不会造成任何损害，尽管肯定会丢失一个。
从理论上讲，这是一个错误的论点，因为您不应该通过“机会”进行编码，但是在实践中，会发生错误，并且使用结尾dir-sep可能最终会减少最终用户的运行时错误。 / p>

通读这个有趣的线程，我没有发现使用结尾dir-sep的任何缺点，只是从理论上讲这是错误的。还是我错过了什么？

Answer 13

约定是一致的。重要的是，要意识到关于 / 属于目录还是文件名的论点是错误的二分法；它不属于任何一个，因为它是一个路径分隔符。

IMO 的正确答案是，如果您的语言提供（或编写您自己的语言），您应该尽可能使用路径操作库，并忽略路径的内部结构，因为它看起来像一个字符串。这将消除知道将斜杠放在哪里的问题，并使您的代码在系统之间更具可移植性。

目录路径变量是否应以尾部斜杠结尾？

13 个答案: