它是任何标准(例如POSIX)的一部分,系统文件应该是小写的吗?

Dar*_*ren 29 filesystems filenames posix

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

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

对我来说,这打破了所有合理的约定,我觉得文件和目录都应该是小写的(在其他应用程序如 MySQL 中有先例,其文件和目录都被称为 mysql,甚至 Apache 和 Tomcat 之类的应用程序也取消了前面的大写字母)。

如果我将此作为错误报告提出,我想提出一个更有力的论据,而不仅仅是“我认为这是错误的”。那么像 POSIX 标准这样的系统文件是否应该是小写的呢?

And*_*nle 44

不,没有为软件包安装目录指定小写名称。

事实上,历史上安装的软件包以/opt提供软件包的公司的全大写股票代码开始,例如SUNWSun Microsystems 或ORCLOracle。

因此,诸如 Sun 的 QFS 文件系统之类的软件包将安装在名为/opt/SUNWqfs.

  • 直到这个关于股票行情的新花絮。赞成。谢谢。 (7认同)
  • @fpmurphy1 也许吧。但是考虑到 Sun 对待 POSIX 合规性的方式,我怀疑他们选择的命名方案会违反标准的任何部分。我也不认为 Sun 在说服 Oracle 使用任何命名方案方面会取得很大成功。 (3认同)
  • 我相信这个约定只适用于 SunOS/Solaris。 (2认同)

Kus*_*nda 27

POSIX 标准有一个部分包含有关符合实用程序的指南(即,“例如那些特定于本地系统或作为更大应用程序的组件编写的程序”),它说

  1. 实用程序名称应介于 2 到 9 个字符之间(含)。
  2. 实用程序名称应包含小写字母(较低的字符分类)和仅来自可移植字符集的数字。

[参考:12.2 实用程序语法指南]

我不清楚“应该包括”这个词的使用是否真的意味着“应该包括”。(下面评论中的共识是它的意思是“应该只包括”)。

Unix 系统上的应用程序不声称是符合 POSIX 的实用程序,否则可以使用它想要的任何名称。如果它确实声称是 POSIX shell 实用程序的一部分的符合 POSIX 的实用程序,则第 12.2 节指南后面的文本表示“应该”将含义更改为“应该”。

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

  • *应用程序*的命名与系统*实用程序*的命名有什么关系? (5认同)
  • 我不认为他们实际上声称在任何地方都符合 POSIX。有趣的是,应用程序名称有 10 个字符长,因此它们在这方面也失败了。顺便说一句,我阅读第 2 点的方式是“它应该只包含小写字母和数字 - 我认为最后的“仅”涵盖了整个条款。也许是 english.stackexchange.com 的问题:) (3认同)
  • XBD 将“应该”定义如下:“对于符合 IEEE Std 1003.1-XXXX 的实现,描述了推荐但非强制性的功能或行为。应用程序不应依赖于该功能或行为的存在。应用程序依赖于这样的特性或行为不能保证在符合要求的实现之间是可移植的。对于应用程序,描述一个特性或行为,它是推荐的编程实践以获得最佳可移植性。” (3认同)
  • 您引用的句子中有一个“唯一”。它出现在短语中的一个尴尬点,可能是由于委员会编辑,但它仍然具有相同的效果。 (3认同)