すべての bin および sbin フォルダーを明確にしましょう (ファイルシステム階層標準より):
/binシステムレベルのバイナリ用/sbinブートローダーとシステム管理者向けの他のシステムレベルのバイナリ用です/usr/bin必須ではないバイナリ用/usr/sbin- ここから混乱が始まります - システム管理者にとって必須のツールではないのですか? どういう意味ですか? 実験用ですか?/usr/local/bin- このフォルダについては何も言及されていない/usr/local/sbin- ローカルにインストールされたシステム管理プログラム。もう一度? どうですか/usr/sbin?
それで質問は、なぜこれほど多くのディレクトリが存在するのか、そして、およびの意味は何なのかということです/usr/sbin。/usr/local/sbin/usr/local/bin
多くのプログラムはアーカイブを通じて配布されており、ソース コードからビルドする必要があります。通常、プログラムには makefile があるため、非常に簡単です。このプロセスでは、特定のプログラム用のフォルダーを作成せずに、usr/local/lib、usr/local/bin... usr/local/whatever にファイルを作成します。
それはなぜでしょうか?
プログラムの作成者が配慮していない場合、プログラムを削除する必要がある場合、そのファイルをすべて手動で削除する必要があるため、これは正しくないと思います。
答え1
1. ディレクトリ構造
これについては、ファイルシステム階層標準 （2.3 PDF）
/bin/ シングル ユーザー モードで使用可能にする必要がある重要なコマンド バイナリ。
すべてのユーザー向け、例: cat、ls、cp
/sbin/ 必須のシステムバイナリ (例: init、ip、mount)。
/usr/bin/ 必須ではないコマンドバイナリ（シングルユーザーモードでは不要）。
すべてのユーザー
/usr/sbin/ さまざまなネットワーク サービスのデーモンなど、必須ではないシステム バイナリ。
/usr/local/ このホストに固有のローカル データの 3 次階層。
通常、さらにサブディレクトリがあります（例：bin/、lib/、share/）
2. インストール
私は可能な限りパッケージ マネージャーを使用します (例: yum または apt-get)。これは非常に多くのアプリケーションで可能ですが、いくつかのケースではリポジトリを追加する必要があります。2 番目に選択するのは RPM などの低レベルのパッケージで、ソースからコンパイルするのは最後の手段です (ただし、これを好む人もいます)
一部のパッケージマネージャーはRPMからインストールできます（例yum install oddity.rpm）
ソースからコンパイルする場合、システム インストーラーが実行した内容を認識できるように独自のパッケージを作成するのは、それほど大きなステップではないでしょう。
すると問題は次のように減少します。yum remove packagename
代替案としては、実行したすべてのシステム管理活動に関する適切な文書を保存することです（私はとにかくテキストファイルにジャーナルを保存しています）
答え2
*/sbin ディレクトリ内のファイルは、システム管理者にのみ役立つ傾向があります。通常のユーザーの場合は、それらを PATH から除外することができます。
単一のディスクに単一の Unix マシンがある場合、異なるディレクトリはあまり意味がありませんが、大規模なシステムと異なるパーティションがある場合は意味があります。これらの習慣の多くは、システムが少し異なっていた 80 年代と 90 年代に作られたものであることを忘れないでください。
/sbinなる傾向がありますとても小さい。これらは、本当に困ったときに必要なユーティリティです。これは、/root と /lib がある最小限のルート パーティションに配置します。/sbin 内のものはすべて静的にリンクされていました。/usr パーティションが困った場合、動的にリンクされたアプリケーションは役に立たなくなるためです。fsck はここにあり、静的にリンクされています。/usr に依存している場合は、当然、/usr/ を fsck することはできません。もちろん、ルート パーティションが困った場合は、非常に困ったことになります。これが、このパーティションが非常に小さい理由です。ここではブロックを非常に少なくすることで、不良ディスク ブロックの可能性を低くします。
/usr/sbinバイナリは、少なくともシングル ユーザー モードにアクセスしてすべてのボリュームをマウントできる一般的なシステム管理ツールです。動的にリンクできます。
バックアップには時間とテープの両面で非常にコストがかかったことを思い出すと、/sbin (正確には / パーティション上の /sbin) と /usr の別々のパーティションも意味をなします。これらが別々のパーティションにある場合は、別々にスケジュールできます。
/usr/localネットワークファイルシステムにすることができます。そのため、多くのマシン間で共有できるローカルに作成されたシステム管理ツールは、/usr/local/sbin に置かれることがあります。当然、ネットワーク修正ユーティリティはそこに置けません。
繰り返しになりますが、多くのことは、ネットワーク環境内の複数のボリュームを持つ管理対象マシン上の大規模なマシンでは理にかなっています。しかし、単一のルート パーティション上の 1 台の Linux マシンでは、そうではありません。
答え3
2 番目の質問は、Superuser で別の質問として投稿する必要があります。最初の質問とは無関係です。
はい、ファイルがあちこちにあるのは困ったものです。だからこそ、パッケージング ソリューションは数多く存在します。RedHat は、どこでも使用されている RPM を作成しました。Solaris には独自のパッケージ形式がありました。HP/UX にも独自のパッケージ形式があり、apt やその他の多くのパッケージ形式があります。適切な場所 (/usr/bin、/usr/lib) に適切な場所に保存しますが、簡単に追加および削除できるようにします。
ソースについては、/usr/local のサブディレクトリで設定およびインストールでき、/usr/local/bin へのシンボリックリンクを処理するツールが以前はありました。パッケージツールが広く普及したため、これはあまり必要ではなく、その名前も忘れてしまいました。
/opt/にインストールしたい人もいるパッケージ名すべてをそこにまとめて保存します。良い点は、すべてが 1 つのディレクトリにあり、アンインストールが であることですrm -rf /opt/packagename。この方法の欠点は、すべてのユーザーの PATH に /opt/packagename/bin を追加する必要があることと、通常、/opt を別のパーティションに置かない人が多く、ルート パーティションがいっぱいになってしまうことです。
答え4
2番目の質問にお答えします。
通常、プログラムはいわゆるパッケージマネージャーパッケージマネージャは通常、バイナリパッケージ（特定のプラットフォーム用にコンパイルされたソフトウェア）を取得してディレクトリに放り込みます（ソースコードをダウンロードして、マシン上でコンパイルしてインストールするものもあります）。したがって、パッケージマネージャは特定の「プログラム」（パッケージ）に属するファイルがどこにあるのかを知っており、パッケージを削除する場合は、パッケージマネージャがすべてクリーンアップします
。
make
そしてインストールする
make install
通常は
make uninstall
ファイルシステムからファイルを削除します。