为什么有些应用程序的文件没有扩展名？
为什么开发人员选择不对某些文件使用文件扩展名？以下是来自 MediaWiki 的示例 -
这似乎是有意为之，例如，“信用”和“复制”可能具有法律意图。他们为什么这样做呢？在什么情况下我应该这样做？
K7A*_*AAY 38
Linux 世界中并没有规定必须有扩展。类 UNIX 操作系统的文件系统不会将扩展元数据与文件名的其余部分分开。点字符只是主文件名中的另一个字符。相反，内部文件元数据普遍编码在文件的开头，以显示打开它的应用程序类型。
如果文件没有扩展名，并且不可执行，则它可能是纯文本文件，尤其是全部大写的文件。
- 我会说，“没有扩展名，*没有可执行权限*，可能是纯文本。” 许多二进制文件，如`/bin/ls` 和`/usr/bin/file`，没有特殊的后缀。没有扩展名且未标记为可执行文件的文件可能是文本文件。一个没有扩展名并且*被*标记为可执行的文件可以是文本（例如，`/usr/bin/tzselect`、`/usr/bin/startx`）或二进制。@J-Dizzle (15认同)
- @J-Dizzle 请允许我改写；没有扩展名，可能是明文。您可能需要一个更强大的文本编辑器来打开它，但它是纯文本的。 (2认同)
- @ilkkachu 这是真的。正如我在对链接问题的回答中所说的那样，我认为人们已经准备好概括为“Linux 这样做，Windows 做另一个”，而实际上这只是惯例和单个程序的行为。 (2认同)
正如 K7AAY 所说，文件名和文件类型之间没有很强的联系，尽管我不同意没有扩展名的文件可能是纯文本。以一定程度确定的方法是使用以下file命令：
$ file *
...
libperconaserverclient18-dev_5.5.44-rel37.3-1.jessie_amd64.deb: Debian binary package (format 2.0)
Percona-Server-5.5.44-37.3-r729fbe2-jessie-x86_64-bundle.tar: POSIX tar archive (GNU)
...
可执行文本文件的类型从第一行读取，如果它#!以脚本需要的任何解释器的绝对路径开头并包含：
$ cat s0
#!/usr/bin/bash
$ file s0
s0: Bourne-Again shell script, ASCII text executable
解释器的路径不检查file，所以它可能指向不存在的东西：
$ cat s1
#!/a/very/long/and/winding/path/flimflam
$ file s1
s1: a /a/very/long/and/winding/path/flimflam script, ASCII text executable
- 这实际上是倒退：如果操作系统无法将文件魔法（前几个字节）识别为可执行的二进制类型（例如，对于我的 Linux 系统上的 64 位 2's-complement little-endian x86_64 ELF，则为 0x7f454c46 02010100），那么系统会假设它是一个shell脚本并将它传递给默认shell进行解释。如果文件魔法是“#!”，则默认 shell 可以被显式覆盖，其中第一行的其余部分被解释为 shell 来执行并将文件作为输入传递。 (2认同)