lsの色：ls出力でフォントの一部が黒になり、他のフォントが緑になるのはなぜですか

いくつかのフォントファイルをAWS（Amazon Linuxを実行）にアップロードし、.ebextensionsのコマンド/usr/share/fontsを使用してそれらをディレクトリに移動しましたcp。

MacからSSHでログインしてを使用するとls -a、一部のファイルの色が異なります。1つのフォントファイルセットが黒で、他のセットは緑です。これが何が原因であるか、そしてそれが私のコードに問題を引き起こすかどうか知りたいです。

AskUbuntuの別の回答から、私はこれらの色を解釈する方法に関するこのキーを見つけました。なぜ.ttfが実行可能になるのか、.ttfsのあるセットが認識され、別のセットは認識されないのか理解できません。

青：ディレクトリ

緑：実行可能または認識済みのデータファイル

スカイブルー：リンクされたファイル

背景が黄色の黄色：デバイス

ピンク：グラフィック画像ファイル

赤：アーカイブファイル

これらのファイルはすべて、アップロード前にさまざまなフォントサイトからMacにダウンロードされました。

ls -lファイルが実行可能かどうかを明確に伝えます。ここには大きな謎はないと思います。さまざまなソースからファイルをダウンロードしましたが、それぞれに何らかの理由で異なる許可ビットが設定されている可能性があります。^*試してみないと色付きのものと他のものを見たくない場合は、chmod -x *.ttfフォントファイルに実行可能ビットを設定する必要はありません。

* _{Matteo Italiaの非常に支持されているコメントは保持されるべきであると述べています：ほとんどの場合、それらは実行可能ビットを格納しないFATまたはNTFSボリュームからコピーされたため、デフォルトでマウントされ、すべてのファイルに実行可能ビットが設定されています。}

lsあなたが実行しているコマンドはのエイリアスのようですls --color

man ls

--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"、シェルはファイルを分析し、スクリプトを渡すための正しいプログラムを見つけようとしますに。

これは、シェルがファイルの最初の行を読み取って、これが実行されることになっているプログラムの「シバン」表記を見つけることによって行われます。

したがって、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'

猫からexecビットを削除していても動作します

$cat myfile

しません。