ls 颜色:为什么 ls 输出中我的一些字体是黑色,另一些是绿色

ls 颜色:为什么 ls 输出中我的一些字体是黑色,另一些是绿色

/usr/share/fonts我将一些字体文件上传到 AWS(运行 Amazon Linux),并使用.ebextensions 中的命令将它们移至该目录cp

当我从 Mac 上 SSH 登录并使用 时ls -a,我看到一些文件的颜色不同 - 一组字体文件是黑色的,而其他文件是绿色的。我很好奇是什么导致了这种情况,并且如果它会给我的代码带来任何问题

运行 AWS Linux 的 Elastic Beanstalk 上的字体目录

ls -la 截图

AskUbuntu 上的另一个答案我找到了如何解释这些颜色的关键。我不明白为什么 .ttf 是可执行的,或者为什么一组 .ttf 会被识别,而不是另一组。

蓝色:目录

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

天蓝色:链接文件

黄黑底:设备

粉色:图形图像文件

红色:存档文件

这些文件在上传之前都是从各个字体网站下载到 Mac 上的。

答案1

ls -l会明确告诉您文件是否可执行。我不认为这里有什么大秘密。您从各种来源下载了文件,每个来源可能由于某种原因设置了不同的权限位。*如果您不喜欢看到一些带有颜色和其他不尝试的chmod -x *.ttf...字体文件不需要设置可执行位。

*正如 Matteo Italia 的高票评论(应该保留)所说:它们很可能是从 FAT 或 NTFS 卷复制的,这些卷不存储可执行位,因此默认情况下安装,以便所有文件都设置了可执行位

答案2

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

曼LS

--color[=WHEN] 对输出进行着色; WHEN 可以是“always”(如果省略则默认)、“auto”或“never”;更多信息如下

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

  • 使用引号:

    “ls”-a

  • 使用完整路径(例如,如果ls位置位于/bin/ls)并查看它是否显示颜色:

    /bin/ls -a

注意:运行ls -la将显示文件的详细信息,您将能够看到每个文件的完整详细信息,这将允许您检查预期的输出ls --color

答案3

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

可执行权限位(一位用于用户,一位用于组,一位用于其他)意味着如果将文件名传递给其中一个 exec 系统调用,内核将继续尝试执行它。

惯例是,只有实际要执行的文件才设置了可执行位。然而,当移动/复制文件时,尤其是在多平台环境中,很容易无意中获得或丢失可执行位。

存储在不支持 unix 权限的文件系统(fat、ntfs 等)上的文件可能会在系统中显示为可执行文件。使用保留权限的工具将这些文件移动或复制到 unix 文件系统将保留这些可执行位。

另一方面,使用工具移动无法保留权限或取消选择保留权限选项的文件可能会导致副本不会被标记为可执行文件,即使原始文件可以被执行。

因此,在使用各种工具在各种平台上移动后,可执行权限位可能会处于相当任意的状态。

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

答案4

正如前面的答案所说,颜色是为了指示文件是否被认为是可执行的。

Linux 和大多数其他 Unix 中的“执行”权限(=位)对文件有一种含义,对目录有另一种含义。

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

对于常规文件(与设备文件和其他特殊 Unix 文件类型相反),执行位意味着如果您在命令行上使用文件名,操作系统(或更准确地说:shell)将尝试“执行”或运行文件作为命令。相反,如果您没有该文件的执行权限,则无法从命令行运行它。

因此,例如,如果您删除所有用户对 /bin/cat 文件(这是一个 Unix 命令)的 x 权限,您自己或任何其他人以及任何尝试使用“cat”命令的程序都将失败。

这些是操作系统命令,例如“cat”和“grep”,它们通常在 /*/bin/ 目录中具有可执行文件 - /bin、/usr/bin、/sbin、/usr/sbin 等。

然后可能存在未编译的解释脚本,这些脚本可以用某种编程语言编写,例如 Python 或 shell 脚本(基本上,您在 ssh 到服务器时就像从命令行编写的命令一样)。

现在,当您在脚本文件(例如文件 foobar)上设置执行位并尝试通过 shell 执行它时:“./foobar”,shell 会尝试分析该文件并找到正确的程序来传递脚本到。

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 中删除了 exec 位并且

$cat myfile

没有。

相关内容