web-dev-qa-db-ja.com

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

Windowsでは、システムドライブC:にprogram_filesというディレクトリがあり、その下に各プログラムが独自のディレクトリがあります。

Linuxでは、/usr/および/usr/local/の下に/bin, /etc, /share, /srcなどがあります。

したがって、Windowsでは、各プログラムのすべてのファイルが同じディレクトリにグループ化されますが、Linuxでは、すべてのプログラムからの同じタイプのファイルがグループ化されます。

Windowsがインストールされたプログラムを整理する方法は、Linuxの方法よりも論理的であり、したがって、インストールされたプログラムは手動で管理する方が簡単です。

Linuxがインストール済みプログラムのファイルを編成する方法の利点は何ですか？ありがとう。

インストールされたプログラムを$ HOMEに整理して、実行時に検索するためにシェルがそれらを検索する方法は？ の問題があるとき、この質問があります。ここで、プログラムを$HOME Windowsの方法ですが、プログラムの検索パスを指定するいくつかの問題があります。

linuxfilesystemssoftware-installationwindows
10
Tim

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は、管理者および通常のユーザーに不可欠なツールです。
17
user147505

今日では、これは古典的なUNIXからの歴史的な継承だと思います。

UNIXの最初のバージョンでは、プログラムは今日ほど大きくありませんでした。プログラムは、多くの場合、システムライブラリを使用する1つの実行可能ファイルから構成されていました。ですから、いくつかの独自のライブラリで構成されるプログラムについては誰も考えませんでした。メインライブラリはCライブラリで、すべてのプログラムがその場所を知っていました。

また、UNIX環境は完成した製品と見なされました（ドキュメントを準備するため）。したがって、すべてのツールへのパスが修正されました。

HDD（ハードディスクドライブ）時代の固定パスからのいくつかの利点は、今日では存在しています。 FSH（ファイルシステム階層）が個別のディスクパーティションに分割され、バイナリとライブラリを含むパーティションをHDDのプライマリセクターの近くに配置すると、プログラムの起動時間が少し速くなります。

7
Yurij Goncharuk

あなたが現代の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規則に従っている場合にインストールします。

3
Simon Richter

目的ごとに個別のファイルを分割するスタイルについて話しているようです（/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ディレクトリ。

2
cjs