Linuxがインストール済みプログラムのファイルを編成する方法の利点は何ですか？[閉まっている]

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はcommon内にマウントされ/usrます。

最後に、PATH私のrootユーザーのを見てください：

# 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ユーティリティはシンボリックリンクを作成し、PATH変数にディレクトリを追加する必要なしに、ソフトウェアを標準パスで使用できるようにします（Windowsのように、クリフトがそこに蓄積する傾向があります）。

しかし、最近のLinuxディストリビューションはすべてを既製のパッケージとして出荷しているため、プログラムは「システム」の一部になっています。パッケージマネージャーがインストールを処理するので、シンボリックリンクは不要であり、プログラムを分離することは有用な目的にはなりません（ただし、多くの小さなディレクトリをスキャンする必要があるため、プログラムの起動が遅くなります）。

ソフトウェアをホームディレクトリにインストールする場合は、GNU stowも使用することをお勧めします。これにより、プログラムを分離しておくことができます。これは、パッケージマネージャーを使用していない場合に適しています。

以下のための私の伝統的なセットアップは一つのディレクトリである~/software/DIR私は、ストウの内部を使用して、にプログラムをインストールすることをDIR作成するには~/software/bin、~/software/shareこの手段は私だけ追加する必要がありますなど~/software/bin、すべての私のインストールしたソフトウェアを取得するには、PATH変数に。

使用する：

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

プログラムがGNU規則に従っている場合にインストールします。

アプリケーションパッケージ（あるディレクトリのC ++コンパイラ、別のディレクトリの画像編集プログラム）ではなく/usr/bin、目的（実行可能ファイル、/usr/libライブラリ）によって個々のファイルを分割するスタイルについて話しているように見えます。Unixシステムでは、この歴史的な理由の多くが存在しますが、Unixライクなシステムをこれに傾ける傾向にある今日の力もあります。システム上のほとんどのプログラムを管理するパッケージマネージャーです。

Windowsでは、歴史的に、そして現在でもかなり多くのアプリケーションが、独自のインストーラー、特にアンインストーラーを提供する責任を負っており、現在でも頻繁に中央アプリケーションリストに登録されていません。このような状況では、アプリケーションがそのファイルのできるだけ多くの「独自の」ディレクトリを持っていることが一般的にはより良いです。これは、他のアプリケーションとの競合を回避するのに役立ちますが、これが常に機能するとは限りません（特にDLLの場合）。

一方、Unixシステムは、90年代以降、一般的に、それぞれが単一の受け入れられたパッケージマネージャーと、このパッケージマネージャーを介して一般的に使用されるソフトウェアを大量に提供するグループを持っていました。（さまざまなUnicesの公式パッケージマネージャーにはyum、aptLinuxシステム、pkgsrcNetBSD、portsFreeBSDが含まれます。市販のUnixシステムもbrew、MacOS など、非公式だが広く受け入れられているパッケージマネージャーになることがよくあります。）

これらのパッケージマネージャーには、システムが所有するさまざまなサブディレクトリ内のシステム上のすべてのファイルを追跡できるという利点があります。ここではすべてのファイルの名前と場所を1つのグループが割り当てているため、グループ間で共有されるディレクトリの小さなセットをすべて使用できます。これは、特にアプリケーション間でファイルを共有し、ライブラリと実行可能ファイルを検索するために必要なパスの数を低く抑えるという分野で、さまざまな利点を提供します。

そうは言っても、Unixでも「アプリケーションごとに個別のディレクトリ」をインストールするという長い伝統があり、通常は/optディレクトリの下にあります。