/usr/share/fonts一部のフォントファイルをAWS（Amazon Linux実行）にアップロードし、.ebextensionsのコマンドを使用してそのディレクトリに移動しましたcp。
MacでSSHを使用して使用すると、ls -a一部のファイルの色が異なるように表示されます。フォントファイルの1つのセットは黒で、もう1つは緑です。原因が何なのか気になります。私のコードに問題が発生した場合。
~からAskUbuntuに対するもう一つの答えこの色をどのように解釈するかについての鍵を見つけました。.ttfsが実行可能な理由または.ttfsセットの1つは認識されますが、他のセットは認識されない理由を理解できません。
青：ディレクトリ
緑：実行可能または認識されたデータファイル
水色：リンクされたファイル
黄色と黒の背景：機器
ピンク：グラフィックイメージファイル
赤：アーカイブされたファイル
これらのファイルは、アップロード前にさまざまなフォントのWebサイトからMacにダウンロードされました。
答え1
ls -lファイルが実行可能かどうかを明示的に通知します。ここには大きな秘密はないようです。さまざまなソースからファイルをダウンロードしましたが、各ソースには何らかの理由で異なる権限ビットが設定されている可能性があります。*一部の色が気に入らず、一部は試していない場合chmod -x *.ttf...フォントファイルに実行ビットを設定する必要はありません。
* Matteo Italiaの賛成意見（残さなければならない）は、次のように述べています。実行可能ビットを格納しないFATまたはNTFSボリュームからコピーされた可能性が高いためすべてのファイルに実行ビットが設定されるようにデフォルトでインストールされます。。
答え2
ls実行中のコマンドがエイリアスのようです。ls --color
--color[=WHEN] 出力色は、「always」（省略した場合はデフォルト）、「auto」、または「never」です。
Originを実行して確認できますls。
引用符を使用する：
"ls"-a
フルパス（たとえば、
ls場所/bin/ls）を使用し、色が表示されていることを確認します。/bin/ls -a
注：実行すると、ls -laファイルの詳細が表示され、各ファイルの完全な詳細を表示できます。これにより、期待される出力を確認できます。ls --color
答え3
色は、ファイルが「実行可能」とマークされていることを示します。*
実行権限ビット（ユーザー用、グループ用、その他用）は、ファイル名がexecシステムコールの1つに渡されると、カーネルが引き続きそのファイルを実行しようとすることを意味します。
実際に実行することを意図したファイルにのみ実行可能ビットが設定されていることが慣例です。ただし、特にマルチプラットフォーム環境でファイルを移動/コピーするときに、誤って実行ビットを取得または失うことは簡単です。
Unix権限（fat、ntfsなど）をサポートしていないファイルシステムに保存されているファイルは、システム上の実行可能ファイルとして表示されることがあります。権限保存ツールを使用してこれらのファイルを Unix ファイルシステムに移動またはコピーすると、これらの実行可能ビットが保存されます。
一方、ツールを使用して権限を保持できなかったファイルを移動したり、権限の保持オプションを選択解除した場合、元のファイルを実行してもコピーが実行可能ファイルとして表示されないことがあります。
したがって、さまざまなツールを使用してさまざまなプラットフォームを移動した後、実行許可ビットが多少ランダムな状態に残ることがあります。
* 実行可能なビットの全部ではなく一部が設定された場合を ls がどのように処理するか 100% 確信できません。
答え4
前の回答で述べたように、色はファイルが実行可能と見なされるかどうかを示します。
Linuxや他のほとんどのUnixでは、「実行」権限（=ビット）はファイルの意味とディレクトリの意味が異なります。
ディレクトリの場合、実行権限がある場合はその内容を表示できます。これを怠ると、そのディレクトリへの読み取りおよび書き込みアクセス権がある場合でもそのディレクトリにcdできず、その中にあるファイルを一覧表示できません。
通常のファイル（デバイスファイルや他の特別なUnixファイルの種類とは対照的）の場合、実行ビットはコマンドラインでファイル名を使用してオペレーティングシステム（またはより正確にはシェル）が「実行」を試みるか、ファイルをOrderとして実行します。逆に、ファイルに対する実行権限がないと、コマンドラインからは実行できません。
したがって、たとえば、/ bin / catファイル（Unixコマンド）に対するすべてのユーザーのx権限を削除すると、「cat」コマンドを使用したいユーザーや他の人、すべてのプログラムが失敗します。
これは "cat"や "grep"などのオペレーティングシステムコマンドで、通常/ * / bin /ディレクトリ（/bin、/usr/bin、/sbin、/usr/sbinなど）に実行可能ファイルがあります。
その後、Pythonやシェルスクリプトなど、いくつかのプログラミング言語で書くことができるコンパイルされていない解釈されたスクリプトがあるかもしれません（デフォルトでは、コマンドラインからコマンドを書くのと同じようにサーバーにsshを使用します）。
スクリプトファイル（foobarファイルなど）に実行ビットを設定し、シェルを介して実行しようとすると、「./foobar」、シェルはファイルを解析し、スクリプトを渡す正しいプログラムを見つけます。 。
シェルは以下を見つけようとし、ファイルの最初の行を読み込みます。「シェバン」のシンボルどのプログラムを実行する必要がありますか？
したがって、foobarが次の最初の行を含むテキストファイルの場合：
#!/usr/bin/python
その後、シェルはcommand：実行を試み/usr/bin/python foobar、デフォルトでPythonインタプリタを呼び出し、foobarファイル名をPythonスクリプトに渡します。
シェルがファイル内の最初の行を見つけられない場合は、シェルコマンドが含まれているかのようにfoobar自体を実行しようとします。
シェルは、実行ビットを含むファイルに有効なシェルコマンドが含まれていない場合にのみ文句を言います。
したがって、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ビットを削除しても、実行のためにシェルの新しいインスタンスに渡すことができます。
$sh -c 'cat myfile'
catからexecビットを削除しても
$cat myfile
いいえ。