/ usr / local / binとは何ですか？
今日まで、私はターミナルを使用して、ディレクトリへの移動やディレクトリからの移動、およびtouchコマンドを使用したファイルの日付の変更を行っていました。 Macに楽しいスクリプトをインストールし、後でファイルを実行可能にするためにファイルをchmod 755する必要があった後、ターミナルの全範囲に気づきました。
/usr/local/binについて教えてください。 /usr/は、コンピューターのユーザーだと思います。しかし、なぜ/local/が存在するのかわかりません。明らかにローカルコンピューターを表していますが、コンピューター（またはサーバー）上にあるため、本当に必要でしょうか。 /usr/binは問題ないでしょうか？
/binとは何ですか？端末にスクリプトをインストールするためにこの領域が通常使用されるのはなぜですか？
/usr/local/binは、通常のユーザーが実行できるプログラム用です。
/usr/local階層は、ソフトウェアをローカルにインストールするときにシステム管理者が使用するためのものです。- システムソフトウェアが更新されたときに上書きされないようにする必要があります。
- ホストのグループ間で共有可能なプログラムとデータに使用できますが、
/usrにはありません。 - ローカルにインストールされたソフトウェアは、
/usr/localのソフトウェアを置換またはアップグレードするためにインストールされている場合を除き、/ usrではなく/usr内に配置する必要があります。
このソースは、深いレベルで ファイルシステム階層標準 を説明するのに役立ちます。
/usr/local/binの使用と乱用に関するこの記事 も興味深いかもしれません。
/ usr /、私はコンピュータのユーザーだと思います。
閉じる。
Unixはマルチユーザーオペレーティングシステムとして始まったため、「ユーザー」ではなく、「users」の複数形です。
AT＆T Unix System V Release 4 （SVR4）が1988年に登場し、ユーザー管理ツールがデフォルトで/homeにユーザーホームディレクトリを作成するようになる前は、従来の場所は/usrでした。$HOMEディレクトリは/usr/jfwであった可能性がありますa システムIII ボックス。
/usrも含まれており、今のところ、/usr/bin、/usr/libなども含まれています。経験から、ホームディレクトリの分離は優れたシステム管理手法であることがわかったため、SVR4での/homeポリシーの変更により、/usrに属していると考えるすべてのものが取り残されました。
/usrにはまだ名前を付ける十分な理由がありました。残ったのは、システムが通常のインタラクティブな使用をサポートするのに十分に起動するまで利用可能である必要のないファイルでした。つまり、残されたのは、OSのuserに焦点を当てた部分でした。つまり、/usrが別の物理ボリューム上にある可能性があり、これは 92 MBのハードディスクドライブが洗濯機のサイズ の時代には良いことでした。
初期のUnixシステムは、/usrボリュームが何らかの理由でマウントできなかった場合でもシングルユーザーモード²で起動できるように、コアOSファイルを/usrに近づけないように注意していた。ルートボリュームには、/usrボリュームをオンラインに戻すのに十分なツールが含まれていました。
小さな組み込みシステムでも、従来のルートボリュームファイルと単一ボリューム上のすべての/usrの両方に十分なスペースがあるため、いくつかのUnixフレーバーはこの古い設計原則を無視します。³Red Hat Enterprise Linux 、SolarisおよびCygwinシンボリックリンク/binから/usr/binおよび/libから/usr/libへのシンボリックリンクにより、これらのディレクトリ間に違いがなくなります。
.../local/...明らかにローカルコンピュータを表します...
はい。これは、/usr/localの下のファイルがその単一のシステムに固有であることになっているという事実を参照しています。総称的なファイルは他の場所に置く必要があります。
これは、Unixシステムがすべて標準化された数十年前に一般的に使用されていた方法にもルーツがあります。繰り返しになりますが、当時のハードディスクはかさばり、本当に高価で、今日の標準ではほとんど保存されていません。ディスクのコストとスペースを節約するために、Unixボックスでいっぱいのコンピューターラボは、NFSまたは他のネットワークファイル共有プロトコルを介して/usrのほとんどを共有することが多いため、各ボックスに独自の冗長コピーを用意する必要はありませんでした。単一のボックスは、/usr/localとは別のボリュームである/usrの下に配置されます。
この歴史的遺産が、手動でインストールされた場合、ほとんどのサードパーティUnixソフトウェアが/usr/localにインストールすることがデフォルトである理由です。このようなソフトウェアのほとんどは、パッケージを別の場所にインストールできますが、選択しないことにより、安全なデフォルトが得られ、特定の目的で他の一般的なインストール場所を妨げることはありません。
代わりにソフトウェアをどこかにインストールすることには十分な理由があります。 AppleのmacOSチームは、たとえば GNU Bashソースコード からbashをビルドするときにこれを行います。これらは、/をインストールプレフィックスとして使用し、/usr/localのデフォルトを上書きして、Bashが/binになるようにします。
別の例は、古いLinuxシステムがGUIソフトウェアを/usr/X11R6に分離して、従来のコマンドラインや curses ベースのソフトウェアから分離する方法です。これは、デフォルトの/usr/localプレフィックスを/usr/X11R6で上書きするだけで行われました。⁵
/ binとは何ですか？
これは「バイナリ」の略であり、このコンテキストでは「プレーンテキストではないファイル」を意味します。このようなファイルのほとんどは、Unixボックスでは 実行可能ファイル であるため、これらの2つの用語は一部のサークルでは同義語となっています。 （「RHEL 7、Fredのバイナリを構築してください。」）
Unixボックス上のテキストファイルは、/etc、/usr/include、/usr/shareなどの別の場所にあります。
むかしむかし、プレーンテキストファイルであるシェルスクリプトでさえbinディレクトリから除外されていましたが、この行も不鮮明でした。現在、binディレクトリには、厳密に「バイナリ」かどうかに関係なく、通常、あらゆる種類の実行可能ファイルが含まれています。⁶
脚注と余談：
SVR4より前のユーザー管理ツールの基本的な性質により、
HOME=/usr/$NAMEスキームは、デフォルトとしてソフトウェアツールによって強制されるのではなく、単なる規則として文書化されていました。" AT＆T Unix System V Release 3.2 System Administrator's Guide の4-8ページでこれを確認できます。==ここでは、AT＆TがSVR4が登場する前のUNIXの最後のメジャーバージョンで古い
/usr/$NAMEスキームを推奨しています。システム管理者がより意味のある別のスキームを選択することは、古いUnixシステムではかなり一般的でした。人々は人々であり、それは多くの異なる計画が発明されたことを意味しました。
/home/$NAMEが標準になる前に出会った1つのスキームは/u/$NAMEでした。私が使用した別のシステム 1990年代初頭には、すべてのホームディレクトリを単一の物理ボリュームに収めることができないほど多くのユーザーがいたため、
/u1/$NAME、/u2/$NAMEなどのスキームを使用しました。思い出します。ホームディレクトリがどのディスクになるかは、アカウントが作成されたときにどのディスクに空き容量があったかという問題でした。押し続けると、macOSボックスをシングルユーザーモードで起動できます Cmd-S 起動中。画面が黒くなり、明るい灰色のテキストが表示されたら、離します。ターミナルで実行するようなものですが、GUIがまだ起動していないため、画面全体を占有します。
注意してください、あなたは
rootとして実行しています。シングルユーザールートプロンプトで「exit」と入力して、シングルユーザーモードを終了し、マルチユーザーGUIモードでの起動を続行します。
重要なシングルユーザーモードのファイルを
/usrに含めないように表示されているUnixのOSは、実際には最近そうではないかもしれません。私はかつて、FreeBSD 9ボックスを/usrをZFSボリュームに移動して起動できないようにしました。 ZFS-on-root機能がFreeBSD 10までリリースされなかったことを忘れてしまいました Catch 22 ：OSは/usrをマウントするために/usrにファイルを必要としました！それは十分に悪いことでしたが、FreeBSD 9がシングルユーザーブートのものを
/usrから除外している場合は、それを修正できたはずです。/usrをマウントできない状態でシングルユーザーモードでも起動しないため、伝統が何らかの形で侵害されていることは明らかです。そのシステムを再起動するには、レスキューCDから起動する必要がありました。これは、
/usr/shareを取得する場所でもあります。これは、異なるプロセッサタイプのUnixボックス間でも共有できるファイルを分離します。通常、テキストファイル：マニュアルページ、辞書など.「X11R6」は、この規則が普及していた当時のLinux GUIを支える X Window System のバージョンを指していました。 Linuxシステムは通常、X11R6が X.Org に置き換えられた頃にGUIソフトウェアの分離を停止しました。
元のUnixシステムは、
/etcの真のバイナリと混同しないように、コアのシェルスクリプトを/binに保持していました。
/usr/local/binは、最新のMac OS（その下にあるBSD）のUNIX風のルートを示しています。
- 「usr」は、UNIXシステムリソースを表します。これは、システムプログラムとライブラリが格納される場所です。
- 「ローカル」は、標準ディストリビューションに付属していないリソースを表し、通常、サイトごとにコンパイルおよび保守されます。
- 「bin」は、バイナリでコンパイルされた実行可能ファイルを表します。
これは、UNIXからLinuxおよびBSDへの初期の実装以降、変化してきましたが、慣例はそのままです。さて、/usr/binは、「メイン」またはコアプログラムおよびライブラリ用で、/usr/local/binは、アドオンおよび重要でないプログラムとライブラリ用です。
一般に構造関連の質問については Wikipedia を参照することをお勧めします。基本をカバーします。
ただし、質問に直接回答するには：
- / usrは、大まかに言って重要ではないシステムライブラリおよび実行可能ファイルです
- / usr/localは、大まかに言えば、非システムライブラリおよび実行可能ファイル用です。
これが、2つの間で同様の構造を見つける傾向がある理由です。/usr/{、local /} {bin、sbin、lib}。シェルの新機能である{}は、シェル拡張です。実行してみてください
ls -ld /usr/{,local/}{bin,sbin,lib}
ローカルシェルからそれがどのように機能するかを確認します。
/usr/local/binは、実行可能ファイル、特にオープンソースファイルの最も一般的なデフォルトの場所です。
ただし、Unixシステムでは/usrが90年代前半に標準化され、オペレーティングシステムに属するファイルの階層を含むようになり、そのOSを使用する複数のシステムで共有できるため、これは間違いなく不適切な選択です。
これらのファイルは静的であるため、/usrファイルシステムは読み取り専用でマウントできます。 /usr/localは、設計上ローカルであるため共有されないため、この標準を無効にしているため、ローカルコンパイルを可能にするために読み書き可能である必要があり、オペレーティングシステムの一部ではありません。 /opt/localのようなひどいものは代わりに選択されませんでした...
Mathematicaなどのインストールする可能性のある商用プログラムには/usr/localを使用することをお勧めします。セットアップするときは、独自のパーティションに配置してください。 OSをアップグレードしても、このパーティションは影響を受けず、その内容を再インストールする必要はありません。したがって、OSのアップグレード間で保持したいものに使用します。
これとは別に、この理由から/homeにも独自のパーティションを割り当てるようにしてください。
この答えも役に立つかもしれません。
/ usr/local
/usr/localの元のアイデアは、/usr以外のすべてのマシンに個別の（「ローカル」）「/ usr」ディレクトリを作成することでした。 /usrの構造をコピーします。
最近、/usr/localは、自己コンパイルまたはサードパーティのプログラムを保持するのに適した場所と広く見なされています。 /usr/local階層は、ソフトウェアをローカルにインストールするときにシステム管理者が使用するためのものです。システムソフトウェアが更新されたときに上書きされないようにする必要があります。
ホストのグループ間で共有されているが/usrにはないプログラムとデータに使用できます。ローカルにインストールされたソフトウェアは、/usr/localのソフトウェアを交換またはアップグレードするためにインストールされている場合を除き、/usrではなく/usr内に配置する必要があります。