系统文件应该小写吗，这是任何标准的一部分（例如POSIX）吗？

我公司转售了一个品牌名称为大小写混合的应用程序，例如“ ApplicationName”。

应用程序的安装程序会在此标准中创建所有路径和文件名。例如，主目录是/opt/ApplicationName，调用了init文件，ApplicationName因此我必须运行service ApplicationName status，依此类推。

对我来说，这违反了所有明智的约定，我认为文件和目录应该全部使用小写（在其他应用程序中（例如MySQL）有先例，MySQL的文件和目录都被称为mysql，甚至像Apache和Tomcat这样的应用程序都取消了前面的内容大写字母）。

如果我将其作为错误报告提出，我想提出一个更有力的论据，而不仅仅是“我认为这是错误的”。那么，是否在类似POSIX标准的文件中规定类似的系统文件应为小写？

filesystems filenames posix

— 达伦
source

您还可以指出，这对您的客户来说是非常烦人的，因为您将迫使他们使用额外的按钮（Shift）。这似乎没什么大不了的（好的，不是），但是很烦人。

— terdon

某些文件系统不区分大小写，值得指出一个简单的错字（例如，某些用户脚本错误地在“ applicationname”处引用了该文件）将在某些系统上有效，而在其他系统上则无效，问题不会立即得到解决，并且以后可能会很昂贵。更明确的“ application_name”不太可能出现此问题。

— Stefan

另一个反例：与X11相关的任何文件名通常都带有大写的X，例如/usr/X11R6、/usr/lib/libX11.so，依此类推。

— nomadictype

X希望成为您今天证明趋势的例外。

— StarWeaver

@nomadictype除了在Unix系统上运行之外，X Windows系统与Unix POSIX标准几乎没有关系。

— Kusalananda

Answers:

POSIX标准的一节包含用于遵循实用程序的准则（即“例如专门针对本地系统编写的或作为较大应用程序的组成部分的那些”），

实用程序名称应介于2到9个字符（包括两个字符）之间。
实用程序名称应仅包含小写字母（小写字符分类）和便携式字符集中的数字。

[参考：12.2实用程序语法准则 ]

目前还不清楚我是否使用的话“应该包括”真正的意思是“应该只包括”。（以下评论中的共识是，它的意思是“应仅包括”）。

Unix系统上不声称是POSIX兼容实用程序的应用程序可能会使用它想要的任何名称。如果确实声称它是POSIX shell实用程序的一部分，并且是 POSIX兼容实用程序，则第12.2节中的准则后面的文字将“应该”更改为“应”。

据我所知，关于目录名称没有类似的指南。macOS（在基于Intel的Mac计算机上运行时是经过认证的UNIX 03产品）/Users用作用户主目录的前缀，以及许多其他大小写混合的目录名。

— 库萨兰达
source

我不认为他们实际上声称在任何地方都符合POSIX。有趣的是，应用程序名称的长度为10个字符，因此它们在该位置也会失败。顺便说一句，我读点2的方式是“它应该只包括小写和数字-我想最后‘只’涵盖整个条款也许对english.stackexchange.com :)一个问题

— 达伦-

XBD定义should如下：“对于符合IEEE Std 1003.1-XXXX的实现，描述了推荐但非强制性的功能或行为。应用程序不应依赖于该功能或行为的存在。依赖于此功能或行为的应用程序不能确保某个特性或行为可以在符合标准的实现中移植。对于应用程序，请描述推荐用于最佳便携性的编程实践的特性或行为。”

— fpmurphy

难道一个命名的应用有什么做的系统命名事业？

— Matti Virkkunen

@IlmariKaronen正确。该准则用于实现标准本身中描述的实用程序。

— Kusalananda

您引用的句子中只有一个“ only”。它可能是由于委员会的编辑而在短语中出现了一个尴尬的地方，但仍然具有相同的效果。

— hobbs

否，未为软件包安装目录指定小写名称。

实际上，从历史上看，安装的软件包/opt始于提供该软件包的公司的全资股票代码，例如SUNWSun Microsystems或ORCLOracle。

因此，诸如Sun的QFS文件系统之类的软件包将安装在名为的目录中/opt/SUNWqfs。

— 安德鲁·汉勒
source

了解有关股票行情自动收录器的最新信息。已投票。谢谢。

— 达伦（Darren）

我相信该约定仅适用于SunOS / Solaris。

— fpmurphy

@ fpmurphy1也许。但是考虑到Sun如何对待POSIX合规性，我怀疑他们选择的命名方案是否会违反该标准的任何部分。我也不认为Sun在说服Oracle使用任何命名方案方面会取得很大的成功。

— 安德鲁·亨利

@ AndrewHenle，SunOS / Solaris的SMI命名方案符合相关的标准和规范。POSIX和单一Unix规范都定义should为实质上是it is recommended

— fpmurphy '17

大写字母的名称感觉很坚韧，并且是从大型机采用的：)

— rackandboneman

除了POSIX准则外，我认为这可能会更加重视用户传统。案例名称为“ ApplicationName”在Wiki爆炸中变得很流行，使一些人（如我）习惯使用大写字母代替连字符，或更糟的是空格。但是，这是在Linux和类似的操作系统流行之后的几年，其背后是很长的Unix传统。

这种传统一直很简单，不仅遵循Kusalananda指出的规则，甚至仅缩写四到六个字符的单词（例如，/usr“用户”，/srv“服务”或/mnt“挂载”）和显然是更长的含义（/sbin对于“超级用户二进制文件”。在这种传统下，大写迫使您按下Shift键，也许还偶然按下了Caps Lock键，这简直就是邪恶。

在某种程度上，这是令人惊讶的，因为Unix长期以来一直能够写区分大小写的长文件名，而相比之下，MS-DOS / Windows只限于不区分大小写的短文件名（八个字符加三个扩展名），但是很快就丢失了。 Windows 95超过此限制时，这种简单性（“程序文件”，“我的文档”等）。

尽管如此，今天还是有一些例外，例如NetworkManager守护程序，并且将来我们可能还会看到更多的WikiWords。但是我们仍然讨厌鼠标，并在终端中写上只能以TabTab自动补全结尾的长名称。或者有人看到一些优势，重命名vim到VisualImproved？

— 弗兰
source

/usr不是“用户”的简写。它是“ Unix系统资源”的简写

— fpmurphy

@ fpmurphy1闻起来像是一个反义词。

— hobbs

@ fpmurphy1 /usr最初是包含用户主目录的目录（如/home今天）。我同意霍布斯的观点。

— 弗朗

在Windows中，My Computer不是，而且从未如此。它纯粹是一个shell构造；您可以通过考虑如何在命令提示符或旧式Win16应用程序中导航到它来说明这一点。Program Files本身就是一个烂摊子，带有本地名称；我最近一次是在昨天遇到这个问题，在该软件中，一个软件采用了英文名称，Program Files但实际使用的名称已本地化在系统上。大概是在Windows 95中微软的糟糕穿帮镜头之一

— 一个CVN

@霍布斯 @Fran只是为/usr和做一个互联网，Unix System Resources 而且，是的，在早期的Unix版本中，用户主目录也位于“ / usr”下

— fpmurphy