Windowsでは、システムドライブC:
にprogram_files
というディレクトリがあり、その下に各プログラムが独自のディレクトリがあります。
Linuxでは、/usr/
および/usr/local/
の下に/bin, /etc, /share, /src
などがあります。
したがって、Windowsでは、各プログラムのすべてのファイルが同じディレクトリにグループ化されますが、Linuxでは、すべてのプログラムからの同じタイプのファイルがグループ化されます。
Windowsがインストールされたプログラムを整理する方法は、Linuxの方法よりも論理的であり、したがって、インストールされたプログラムは手動で管理する方が簡単です。
Linuxがインストール済みプログラムのファイルを編成する方法の利点は何ですか?ありがとう。
インストールされたプログラムを$ HOMEに整理して、実行時に検索するためにシェルがそれらを検索する方法は? の問題があるとき、この質問があります。ここで、プログラムを$HOME
Windowsの方法ですが、プログラムの検索パスを指定するいくつかの問題があります。
Linuxでは、通常、さまざまな場所が適切に保守されている場合、いくつかのロジックをミラーリングします。例えば。:
/bin
には、最も基本的なツール(プログラム)が含まれています/sbin
には、最も基本的な管理プログラムが含まれていますどちらにも、起動や基本的なトラブルシューティングで使用される基本的なコマンドが含まれています。そして、ここで最初の違いがわかります。一部のプログラムは、通常のユーザーによる使用を目的としていません。
次に、/usr/bin
をご覧ください。ここには、より多くのコマンド(プログラム)の選択肢が見つかるはずです。これらは標準的なツールですが、/bin
および/sbin
のツールほど重要ではありません。
/usr/bin
にはコマンドが含まれていますが、構成ファイルは他の場所にあります。これはどちらも機能エンティティ(プログラム)とその構成ファイルおよびその他のファイルを分離しますが、ユーザー機能の点では、コマンドが他のものと混在していないため、PATH
変数を簡単に使用できるので便利です実行可能ファイルを指します。また、明快さを紹介します。実行可能である必要があります。
私のPATH
を見てください。
$ echo "$PATH" | Perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games
直接呼び出すことができるコマンドを含む場所が6つあります(つまり、パスではなく、実行可能ファイルの名前で)。
/home/tomas/bin
は、プライベート実行可能ファイル用のホームフォルダー内のプライベートディレクトリです。/usr/local/bin
以下で個別に説明します。/usr/bin
については、上記で説明しています。/bin
についても前述しています。/usr/local/games
は/usr/local
(下記で説明)とゲームの組み合わせです/usr/games
はゲームです。ユーティリティ実行可能ファイルと混合しないでください。それらは別々の場所にあります。/usr/local/bin
に移動します。これはやや滑りやすく、すでにここで説明されています / usr/local/binとは 。それを理解するには、フォルダ/usr
が多くのマシンで共有され、ネットの場所からマウントされる可能性があることを知っている必要があります。前述のように、/bin
のコマンドとは異なり、そこにあるコマンドは起動時に必要ないため、その場所は起動プロセスの後の段階でマウントできます。また、読み取り専用でマウントすることもできます。一方、/usr/local/bin
はローカルにインストールされたプログラム用であり、書き込み可能である必要があります。そのため、多くのネットワークマシンは一般的な/usr
ディレクトリを共有する可能性がありますが、それぞれが独自の/usr/local
を共通の/usr
内にマウントします。
最後に、私のrootユーザーのPATH
を見てください。
# echo "$PATH" | Perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
次のものが含まれます。
/usr/local/sbin
の管理コマンドを含む/usr/local
/usr/local/bin
。通常のユーザーが使用できるものと同じです。繰り返しますが、それらのタイプは/usr/local
として記述できます。/usr/sbin
は、必須ではない管理ユーティリティです。/usr/bin
は、必須ではない管理および通常のユーザーユーティリティです。/sbin
は必須の管理ツールです。/bin
は、管理者および通常のユーザーに不可欠なツールです。今日では、これは古典的なUNIXからの歴史的な継承だと思います。
UNIXの最初のバージョンでは、プログラムは今日ほど大きくありませんでした。プログラムは、多くの場合、システムライブラリを使用する1つの実行可能ファイルから構成されていました。ですから、いくつかの独自のライブラリで構成されるプログラムについては誰も考えませんでした。メインライブラリはCライブラリで、すべてのプログラムがその場所を知っていました。
また、UNIX環境は完成した製品と見なされました(ドキュメントを準備するため)。したがって、すべてのツールへのパスが修正されました。
HDD(ハードディスクドライブ)時代の固定パスからのいくつかの利点は、今日では存在しています。 FSH(ファイルシステム階層)が個別のディスクパーティションに分割され、バイナリとライブラリを含むパーティションをHDDのプライマリセクターの近くに配置すると、プログラムの起動時間が少し速くなります。
あなたが現代のUnixライクなシステムとして見るものは、本当に伝統的ではありません。
通常、システムユーティリティのみを含むかなり最小限の/
および/usr
階層があり、プログラムは/usr/local
のサブディレクトリに個別にインストールされ、シンボリックリンクを作成することによって使用可能になります。
GNUソフトウェアの非常に典型的な設定は、
./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1
GNU stow ユーティリティはシンボリックリンクを作成し、標準パスでソフトウェアを使用できるようにします。WindowsのようにディレクトリをPATH変数に追加する必要はありません。そこに蓄積する傾向があります)。
ただし、最新のLinuxディストリビューションはすべてを既製のパッケージとして出荷するため、プログラムは「システム」の一部になっています。パッケージマネージャーがインストールを処理するため、シンボリックリンクは必要ありません。プログラムを分離しても、役に立ちません(ただし、多くの小さなディレクトリをスキャンする必要があるため、プログラムの起動が遅くなります)。
ソフトウェアをホームディレクトリにインストールする場合は、GNU stowも使用することをお勧めします。これにより、プログラムを分離しておくことができます。これを使用していない場合は賢明です。パッケージマネージャー。
そのための私の従来のセットアップは、プログラムをインストールする1つのディレクトリ~/software/DIR
であり、次にDIR
内にstowを使用して~/software/bin
、~/software/share
などを作成します。これは、インストールされているすべてのソフトウェアを取得するには、PATH変数に~/software/bin
を追加します。
使用する:
./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1
プログラムがGNU規則に従っている場合にインストールします。
目的ごとに個別のファイルを分割するスタイルについて話しているようです(/usr/bin
実行可能ファイル、/usr/lib
(ライブラリの場合)アプリケーションパッケージではなく(あるディレクトリにC++コンパイラ、別のディレクトリに画像編集プログラム)。 Unixシステムでは、この歴史的な理由の多くが存在しますが、Unixライクなシステムをこれに傾ける傾向にある今日の力もあります。それは、システム上のほとんどのプログラムを管理するパッケージマネージャーです。
Windowsでは、歴史的かつ現在でもかなり多くのアプリケーションが、独自のインストーラー、特にアンインストーラーを提供する責任を負っており、現在でも、中央のアプリケーションリストに登録されていないことがよくあります。このような状況では、アプリケーションができるだけ多くのファイル用の「独自の」ディレクトリを持っている方が一般的には優れています。これは他のアプリケーションとの競合を回避するのに役立ちますが、これが常にうまくいくとは限りません(特に DLLs の場合)。
一方、Unixシステムは、90年代以降、一般的に、それぞれ受け入れられた単一のパッケージマネージャーと、このパッケージマネージャーを介して一般的に使用される大量のソフトウェアを提供するグループを持っていました。 (さまざまなUnicesの公式パッケージマネージャには、Linuxシステムの場合はyum
およびapt
、NetBSDの場合はpkgsrc
、FreeBSDの場合はports
が含まれます。多くの場合、商用Unixシステムも終了します非公式だが広く受け入れられているパッケージマネージャー(MacOSの場合はbrew
など)も用意されています。)
これらのパッケージマネージャには、システムが所有するさまざまなサブディレクトリ内のすべてのファイルを追跡できるという利点があります。ここではすべてのファイルの名前と場所を1つのグループが割り当てているため、すべてのグループが共有する少数のディレクトリを使用できます。これは、特にアプリケーション間でファイルを共有し、ライブラリと実行可能ファイルを検索するために必要なパスの数を低く抑えるという分野で、さまざまな利点を提供します。
そうは言っても、Unixにも「アプリケーションごとに個別のディレクトリ」をインストールするという長い伝統があり、通常は/opt
ディレクトリ。