ls颜色：ls输出中为什么我的某些字体是黑色的而其他字体是绿色的

我将一些字体文件上传到AWS（运行Amazon Linux），并/usr/share/fonts使用cp.ebextensions中的命令将它们移动到目录中。

当我从Mac进行SSH登录并使用时ls -a，我看到一些文件的颜色不同-一组字体文件为黑色，而另一些字体文件为绿色。我很好奇是什么原因造成的，是否会对我的代码造成任何问题。

从AskUbuntu的另一个答案中，我发现了如何解释这些颜色的关键。我不明白为什么.ttf文件是可执行文件，或者为什么一组.ttfs文件会被识别，而另一组文件却不能被识别。

蓝色：目录

绿色：可执行或已识别的数据文件

天蓝色：链接的文件

黄色，黑色背景：设备

粉色：图形图像文件

红色：存档文件

在上传之前，这些文件都已从各种字体站点下载到Mac。

ls -l将明确告诉您文件是否可执行。我认为这里没有什么大谜。您从各种来源下载了文件，每个文件可能出于某种原因而设置了不同的权限位。^*如果您不喜欢看到一些带有颜色的内容，而另一些则不尝试chmod -x *.ttf...字体文件应该不需要可执行位。

* _{正如Matteo Italia高度支持的评论（应该保留）说：很可能它们是从FAT或NTFS卷复制的，它们不存储可执行位，因此默认情况下会挂载，以便所有文件都具有可执行位。}

似乎ls您正在执行的命令是的别名ls --color

人ls

--color [= WHEN]为输出着色；WHEN可以是“ always”（始终）（如果省略则为默认值），“ auto”或“ never”；下面的更多信息

您可以通过运行origin检查它ls：

• 使用引号：

  “ ls” -a

• 使用完整路径（例如，如果lslocation在中/bin/ls），看看它是否显示颜色：

  / bin / ls -a

注意：运行时ls -la将向您显示文件的详细信息，并且您将能够看到每个文件的完整详细信息，这将使您可以查看的预期输出ls --color

颜色表示文件被标记为“可执行” *

可执行权限位（一个给用户，一个给组，一个给其他）意味着，如果文件名传递给exec系统调用之一，则内核将继续尝试并执行它。

约定只有实际打算执行的文件才具有可执行位。但是，在移动/复制文件时，尤其是在多平台环境中，很容易在无意间增加或丢失可执行位。

存储在不支持UNIX权限（胖，ntfs等）的文件系统上的文件可能会在系统中显示为可执行文件。使用保留权限的工具将这些文件移动或复制到UNIX文件系统中，然后将保留这些可执行位。

另一方面，使用工具移动无法保留权限的文件或将其与保留取消选中的权限的选项一起使用的文件可能会导致即使原始副本仍未将副本标记为可执行文件。

因此，在使用各种工具在各种平台上移动之后，可执行权限位可能最终处于任意状态。

*我不确定100％ls如何处理设置了某些但不是全部可执行位的情况。

如先前的回答所述，着色是指示文件是否被视为可执行文件。

在Linux和大多数其他Unix中，“执行”权限（= bit）对文件具有一种含义，对目录具有另一种含义。

对于目录，如果您具有执行权限，则可以查看其内容。如果不这样做，就不能cd到该目录，也不能列出其中的文件，即使您同时具有对目录的读写访问权限。

对于常规文件（与设备文件和其他特殊的Unix文件类型相反），execute位意味着，如果在命令行上使用文件名，则O / S（或更准确地说是：shell）将尝试“执行”或运行该文件作为命令。相反，如果您没有该文件的执行权限，则无法从命令行运行它。

因此，例如，如果您自己或其他任何人从/ bin / cat文件（这是Unix命令）上的所有用户删除x权限，则任何尝试使用“ cat”命令的程序都会失败。

然后是那些OS命令，例如“ cat”和“ grep”，它们通常在/ * / bin /目录中具有可执行文件-/ bin，/ usr / bin，/ sbin，/ usr / sbin等。

然后可能会有未编译的解释性脚本，这些脚本是用某种编程语言编写的，例如Python或Shell脚本（基本上，您在切入服务器时就像从命令行编写的命令一样）。

现在，当您在脚本文件（例如，文件foobar）上设置了执行位，并尝试通过外壳程序“ ./foobar”执行它时，外壳程序将尝试分析文件并找到正确的程序来传递脚本至。

Shell通过尝试读取文件的第一行并找到应该运行哪个程序的“ shebang”符号来完成此操作。

因此，如果您的foobar是带有第一行的文本文件，如下所示：

#!/usr/bin/python

然后，shell会尝试执行command /usr/bin/python foobar：，基本上是调用python解释器并将foobar文件的名称作为Python脚本传递给它。

如果shell在文件中找不到第一行，那么它将尝试执行foobar本身，就好像它包含shell命令一样。

但是，如果具有可执行位的文件不包含有效的Shell命令，则该Shell只会抱怨。

因此，如果您具有设置了exec位的TTF文件并尝试从命令行运行它，就会发生这种情况：

$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$

因此，对于字体，如果未设置exec位，但实际上并没有进行任何更改，则可能会更整洁。

PS只是一些无关的信息。如果确实删除某些命令或脚本上的执行位，则它可能仍会作为参数传递给任何其他程序。如果其他程序知道如何执行命令，则删除exec位并不重要。例如，如果仅从命令行执行操作，foobar Python脚本仍将由Python解释器运行：

$python foobar

代替

$./foobar

与系统命令示例相同，例如“ cat”。如果从“ cat”中删除exec位，您仍然可以将其传递给新的Shell实例以执行：

$sh -c 'cat myfile'

即使您已经从cat和

$cat myfile

没有。