ls色：ls出力で一部のフォントが黒で、他のフォントが緑になるのはなぜですか
いくつかのフォントファイルをAWS（Amazon Linuxを実行）にアップロードし、.ebextensionsのcpコマンドを使用して/usr/share/fontsディレクトリに移動しました。
MacからSSHで接続してls -aを使用すると、一部のファイルが異なる色で表示されます。フォントファイルの1つのセットは黒で、他のセットは緑です。これがなぜそうなったのか、コードに問題が発生するかどうかに興味があります。
から AskUbuntuの別の回答 これらの色を解釈する方法についてこのキーを見つけました。 なぜ.ttfが実行可能なのか、.ttfsのあるセットが認識され、別のセットが認識されないのか理解できません。
青：ディレクトリ
緑：実行可能または認識済みのデータファイル
スカイブルー：リンクされたファイル
背景が黄色の黄色：デバイス
ピンク：グラフィック画像ファイル
赤：アーカイブファイル
これらのファイルはすべて、アップロード前にさまざまなフォントサイトからMacにダウンロードされました。
実行中のlsコマンドはls --colorのエイリアスのようです
--color [= WHEN]出力をカラー化します。 WHENは、 'always'（省略した場合のデフォルト）、 'auto'、または 'never'にすることができます。以下の詳細情報
Origin lsを実行して確認できます。
引用符を使用：
"ls" -a
フルパスを使用して（たとえば、
lsの場所が/bin/lsにある場合）、色が表示されるかどうかを確認します。/ bin/ls -a
注：ls -laを実行すると、ファイルの詳細が表示され、各ファイルの完全な詳細を確認できるため、ls --colorの予想される出力を確認できます。
色は、ファイルが「実行可能」としてマークされていることを示しています*
実行許可ビット（ユーザー用、グループ用、その他用）は、ファイルの名前がexecシステムコールの1つに渡されると、カーネルが先に進み、それを実行しようとすることを意味します。
慣例として、実際に実行されることが意図されているファイルのみに実行可能ビットが設定されています。ただし、ファイルを移動/コピーする場合、特にマルチプラットフォーム環境では、実行ビットが誤って取得または失われる可能性があります。
UNIXのアクセス権（fat、ntfsなど）をサポートしていないファイルシステムに保存されているファイルは、システムから実行可能ファイルとして表示される可能性があります。アクセス許可を保持するツールを使用してこれらのファイルをUNIXファイルシステムに移動またはコピーすると、それらの実行可能ビットが保持されます。
一方、アクセス許可を保持できないか、アクセス許可を保持しないオプションを選択してファイルを移動するツールを使用すると、元のファイルがコピーされていたとしても、コピーが実行可能としてマークされない可能性があります。
したがって、さまざまなツールを使用してさまざまなプラットフォーム内を移動した後、実行許可ビットはかなり恣意的な状態になる可能性があります。
*実行可能ビットのすべてではなく一部が設定されている場合に、lsがどのように処理するかは100％わかりません。
以前の回答で述べたように、色付けは、ファイルが実行可能と見なされるかどうかを示すためのものです。
Linuxおよび他のほとんどのUnixでの「実行」権限（=ビット）には、ファイルに対する意味とディレクトリに対する意味があります。
ディレクトリの場合、実行権限があれば、その内容を確認できます。そうしないと、ディレクトリへのcdアクセスやディレクトリへの読み取りと書き込みの両方のアクセス権がある場合でも、その中のファイルを一覧表示できません。
通常のファイル（デバイスファイルやその他の特別なUnixファイルタイプとは対照的）の場合、実行ビットは、コマンドラインでファイル名を使用すると、O/S（より正確には、シェル）が「実行」または実行しようとすることを意味しますコマンドとしてのファイル。逆に、ファイルに対する実行権限がない場合、コマンドラインから実行することはできません。
したがって、たとえば、/ bin/catファイル（UNIXコマンド）のすべてのユーザーからxパーミッションを削除すると、自分自身または他の誰かが「cat」コマンドを使用しようとすると、プログラムが失敗します。
これらは、 "cat"や "grep"などのOSコマンドであり、通常、/ */bin /ディレクトリ（/ bin、/ usr/bin、/ sbin、/ usr/sbinなど）に実行可能ファイルがあります。
そして、Pythonまたはシェルスクリプト（基本的に、サーバーにsshするときにコマンドラインから作成するようなコマンド）などのプログラミング言語で書かれた、コンパイルされていない解釈済みスクリプトが存在する可能性があります。
ここで、スクリプトファイル（たとえば、ファイルfoobar）に実行ビットを設定し、それをシェルで実行しようとすると、 "./ foobar"、シェルはファイルを分析し、スクリプトを渡すための正しいプログラムを見つけようとしますに。
これは、シェルがファイルの最初の行を読み取って、実行するプログラムの "Shebang"表記 を見つけることによって行います。
したがって、foobarが最初の行が次のようなテキストファイルである場合：
#!/usr/bin/python
次に、シェルはコマンドを実行しようとします：/usr/bin/python foobar、基本的にpythonインタプリタを呼び出し、それにfoobarファイルの名前をPythonスクリプトとして渡します。
シェルがファイル内にそのような最初の行を見つけられない場合、シェルコマンドが含まれているかのように、foobar自体を実行しようとします。
ただし、実行可能ビットを含むファイルに有効なシェルコマンドが含まれていない場合、シェルは単にメッセージを表示します。
したがって、execビットが設定されたTTFファイルがあり、コマンドラインから実行しようとすると、次のようになります。
$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$
したがって、フォントの場合、execビットが設定されていなくても実際には何も変更されない場合は、きちんと整えられます。
追伸ほんの一部の無関係な情報。コマンドまたはスクリプトの実行ビットを削除した場合でも、引数として他のプログラムに渡される可能性があります。他のプログラムがコマンドを実行する方法を知っている場合、execビットの削除は重要ではありませんでした。たとえば、foobar Pythonスクリプトは、コマンドラインから単純に実行した場合でも、Pythonインタープリターによって実行されます。
$python foobar
の代わりに
$./foobar
「cat」などのシステムコマンドの例と同じです。 「cat」からexecビットを削除した場合でも、実行のためにそれをシェルの新しいインスタンスに渡すことができます。
$sh -c 'cat myfile'
猫からexecビットを削除していても動作します
$cat myfile
しません。