Unix 文件命名约定

Question

Unix 文件命名约定

71 filenames

我想知道 Unix 中文件的命名约定是什么？我不确定这一点，但我认为可能有一个应该遵循的通用命名约定？

例如，我想命名一个文件说：backupwith part 2andrandom

我应该这样做吗：

backup_part2_random

或者

backup-part2-random

或者

backup.part2.random

我希望这个问题很清楚。基本上，我想选择一种符合 Unix 哲学的格式。

Answer 1

Mik*_*kel 66

.用于分隔文件类型扩展名，例如foo.txt.

-或_用于分隔逻辑词，例如my-big-file.txt或有时my_big_file.txt。 -更好，因为您不必按 Shift 键（至少使用标准的美国英语 PC 键盘），其他人更喜欢，_因为它看起来更像一个空格。

所以如果我理解你的例子，backup-part2-random或者backup_part2_random最接近正常的 Unix 约定。

CamelCase 通常不用于 Linux/Unix 系统。在看看文件名/bin和/usr/bin。CamelCase 是 Unix 和 Linux 系统上的例外而不是规则。

（这NetworkManager是我能想到的唯一一个使用 CamelCase 的例子，它是由 Mac 开发人员编写的。许多人抱怨这种名称选择。在 Ubuntu 上，他们实际上已将脚本重命名为network-manager.）

例如，/usr/bin在我的系统上：

$ ls -d [A-Z]* | wc -w    # files starting with a capital
6
$ ls -d *_* | wc -w       # files containing an underscore
178
$ ls -d *-* | wc -w       # files containing a minus/dash
409

Run Code Online (Sandbox Code Playgroud)

即便如此，以大写开头的文件都没有使用 CamelCase：

$ ls -d [A-Z]*
GET  HEAD  POST  X11  Xvnc  Xvnc4

Run Code Online (Sandbox Code Playgroud)

+1 为参考。（@Proletariat，`/usr/bin` 的`ls` 输出*是* 参考。这是一个关于*约定的问题。*） (3认同)

Answer 2

Dav*_*ill 42

远更重要的是一个特定的约定是一致的。选择一种风格，并坚持下去。

Answer 3

Law*_*ceC 22

我对 Unix/Linux 文件名约定的看法：

Unix/Linux 文件系统本身并不支持扩展的概念。文件扩展名的概念，一些支持工具如完全存在cp，ls或者您使用的shell。我相信在 NTFS 上也是这样，但我可能是错的。
可执行文件，包括 shell 脚本，通常没有任何类型的扩展名。脚本将有一个 hashbang 行（即#!/bin/bash）标识应该解释它的程序。
任何两个字母长的可执行文件都非常重要。所以不要把你的可执行文件命名为两个字母的文件名。任何以 in/etc结尾的文件tab也非常重要，例如fstab, mtab, inittab.
有时.d会附加到目录名称，特别是在/etc，但这并不普遍（更新：https : //serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux）
rc广泛用于配置脚本或文件，无论是前置（例如，rc.local）还是后缀（.vimrc）
Unix/Linux 社区从未对扩展设置三个字符的限制，并且不赞成缩短众所周知的扩展以适应。例如，不要.htm在 Unix/Linux 上的 HTML 文件末尾使用，而是使用.html.
在一组文件中，文件名有时大写或全部大写，因此它出现在目录列表的开头。经典示例Makefile在源包中。只对像README.
~用于标识备份文件或目录，如important_stuff~、或/etc~。许多贝壳会单独扩展~到$HOME.
库文件几乎总是以lib. 例外是zlib，可能还有其他一些。
有时被 inetd 调用的脚本用前导标记in.，例如in.tftpd.
结尾的 z invmlinuz表示已压缩，但我从未见过任何其他以这种方式命名的文件。

我发现使用“.sh”、“.py”、“.pl”等很方便，并且一些文本编辑器（例如 Geany）使用这些来对正确的语法突出显示方案进行初步猜测。 (6认同)
突然想到，强调它是基于文本的脚本而不是二进制文件这一事实很有用。 (5认同)
我经常看到带有“.sh”“扩展名”的 shell 脚本。我个人觉得它有点烦人，但我不得不承认我可能不知道使用`.sh`的一些很好的理由。 (3认同)
@Wildcard 从那以后（6 年前）我就养成了同样的习惯。该扩展实际上对采购脚本位很有意义。例如，从为 zsh 编写的可执行脚本（即顶部的 `#!/bin/zsh`）你知道你可以安全地获取另一个扩展名为 .zsh 的文件，并确保它包含合法的 zsh 代码。如果您的可执行脚本严格符合 Bourne Shell（即顶部的 `#!/bin/sh`），那么您就会知道获取该 .zsh 文件将会有问题。 (3认同)

Answer 4

gel*_*aen 7

在 unix 中，文件名只是一个字符串，不像 DOS，文件名由名称和扩展名组成。所以任何给定的文件名都是完全可以接受的。

但是很多程序仍然使用以点开头的文件后缀来区分不同的文件类型，即 Apache Web Server 使用后缀来设置答案标题中正确的 MIME 类型。

虽然 gelraen 是 100% 正确的：Unix/Linux 本身并不关心文件扩展名，但现代风格的 Linux 确实关心，因为某些 shell 扩展名提供某些文件类型的特殊标识（颜色或其他），文件管理器提供自动关联与程序。但同样重要的是让人类用户知道哪个文件是什么类型。为此，坚持一个标准方案是很方便的，不仅与自己一致，而且与他人一致。在这方面，事情不应该与 MS Windows（或 MIME）有太大不同。 (5认同)

Answer 5

小智 6

两个想法：

在GNU 编码标准Naming Variables, Functions, and Files部分，您会发现：

请使用下划线分隔名称中的单词，以便 Emacs 单词命令在其中有用。坚持小写；

虽然 IMO 说“你应该使用_emacs”似乎有点过时，但它仍然在他们的“标准”文件中。
让我们暂时假设我们都同意 linux 内核是 linux 项目的万能*，并且那里使用的约定可以被视为“标准”约定。

grep-ing linux 内核的源代码，您会发现以下内容：
- 44.6%的时间只使用破折号
- 54.1%的时间只下划线
- 1.2%的时间文件同时使用两者。

有趣的是，git的源代码中，破折号占85%，下划线占 3.8 %，两者占 11.1%。

选择是明确的，争论不休。;)

个人意见：我使用破折号是出于审美和转移关键原因。如果您在团队中工作，请投票。但是要重申所说的话，请保持一致。

*或“be_all 和 end_all”（如果您愿意）

Answer 6

Bil*_*hor 5

坚持使用字母数字文件名。避免使用空格或用下划线 ( _ ) 替换空格。将文件名中的标点符号限制为句点 (.)、下划线 (_) 和连字符 (-)。通常文件名是小写的，但是当文件名中有多个单词时，我会使用 CamelCase。

使用指示文件类型的扩展名。程序不需要扩展，因为执行位用于指示程序，并且外壳程序知道如何运行各种类型的程序。对于 shell 脚本来说是 (.sh)，对于 perl 脚本来说是 (.pl)，这很常见但不是必需的。Windows 可执行文件扩展名 .bat、.com、.scr 和 .exe 表示 Unix 上的 Windows 可执行文件。

选择一个标准并坚持下去。但如果你避免它，它不会破坏事情。

隐藏（或点）文件的名称以句点开头。这些通常不会出现在目录列表中。使用 'ls -a' 将点文件包含在列表中。

CamelCase 是 Unix 上的反模式。OP 正在询问约定。 (6认同)
这不是“坏”对“好”。这是“这是通常的做法”。这是 OP 要求的 _convention_。原因？可能是因为 Unix 人不喜欢按 Shift，也可能是因为旧系统只有大写字母，或者其他原因。我不知道。 (2认同)

Answer 7

小智 4

文件名中不应使用的字符：

| ; ，！@# $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^

您应该使用字符分隔符来使名称更易于阅读：

_ - . :

（在某些情况下“：”有特殊含义）

当然，您*不能*在文件名中使用“/”。其他一切皆有可能。如果你想让它变得难以访问，甚至有用;-) (6认同)

归档时间：	15 年，2 月前
查看次数：	72130 次
最近记录：	5 年，10 月前