/ 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のは、マルチユーザ・オペレーティング・システムとして始まったので、「ユーザーは、」それは「だではないユーザー、」複数。

1988年にAT＆T Unix System Vリリース4（SVR4）がリリースされる前は、ユーザー管理ツールがデフォルトでユーザーホームディレクトリを作成していました/homeが、従来の場所は/usr.¹ でした。$HOMEディレクトリはSystem IIIボックス/usr/jfwにあったかもしれません。

/usrまた、その後、今のように、含まれている/usr/bin、/usr/lib経験など、ホームディレクトリを分離することは良いシステム管理の実践であることを示した、とのように、/homeSVR4での政策変更、それは我々が今に属すると考えるすべてのものを残しました/usr。

/usrまだ名前を保持する正当な理由がありました：残されたのは、通常のインタラクティブな使用をサポートするのに十分なほどシステムが起動されるまで利用可能である必要がなかったファイルでした。つまり、残されたのはOSのユーザー中心の部分でした。これは/usr、別の物理ボリューム上にある可能性があることを意味しました。これは、洗濯機のサイズの92 MBのハードディスクドライブの時代には良いことでした。

初期のUnixシステムでは/usr、/usrボリュームが何らかの理由でマウントできなかった場合でもシングルユーザーモード²で起動できるように、コアOSファイルが入らないように注意していました。ルートボリュームには、/usrボリュームをオンラインに戻すのに十分なツールが含まれていました。

小さな組み込みシステムは、従来のルート・ボリューム・ファイルの両方のための十分な余地があるので、いくつかのUnixのフレーバーが今、この古い設計原理を無視しないと、すべての/usr単一volume.³のRed Hat Enterprise Linux、SolarisおよびCygwinのシンボリックリンク上を/binする/usr/binと/libして/usr/lib何があるので、これらのディレクトリ間の差が長くなります。

... / local / ...明らかにローカルコンピューターを表します...

はい。これは、配下のファイル/usr/localがその単一システムに固有であると想定されているという事実を指します。汎用的なファイルは、他の場所に存在する必要があります。

また、これは、すべてが標準化された数十年前にUnixシステムが一般的に使用されていた方法にルーツを持っています。繰り返しますが、当時のハードディスクはかさばり、非常に高価で、今日の標準ではほとんど保管されていませんでした。ディスク上のお金とスペースを節約するために、Unixボックスでいっぱいのコンピューターラボは、多くの場合/usr、NFSまたは他のネットワークファイル共有プロトコルを介して大部分を共有するため、各ボックスに独自の冗長コピーは必要ありません。ボックスが下/usr/localに入るでしょう/usr。

この歴史的遺産は/usr/local、手作業でインストールした場合、ほとんどのサードパーティ製Unixソフトウェアのデフォルトのインストール先である理由です。このようなソフトウェアのほとんどは、パッケージを別の場所にインストールできますが、選択しないことにより、安全なデフォルトを取得できます。

代わりにソフトウェアを別の場所にインストールするのには十分な理由があります。AppleのmacOSチームは、たとえばGNU Bashソースコードbashからビルドするときにこれを行います。これら/はインストール接頭辞として使用され、/usr/localデフォルトを上書きして、Bashが最終的にになるようにします/bin。

もう1つの例は、古いLinuxシステムがGUIソフトウェアを/usr/X11R6に分離して、従来のコマンドラインおよびcursesベースのソフトウェアから分離する方法です。これは、単にデフォルトの/usr/localプレフィックスを/usr/X11R6.⁵でオーバーライドすることで行われました。

/ binとは何ですか？

これは「バイナリ」の略で、このコンテキストでは「プレーンテキストではないファイル」を意味します。そのようなファイルのほとんどは、Unixボックスで実行可能ファイルであるため、これら2つの用語は、一部のサークルでは同義語になっています。（「RHEL 7、Fredのバイナリをビルドしてください。」）

Unixのボックスにテキストファイルを別の場所に住んでいる：/etc、/usr/include、/usr/share、など

むかしむかし、プレーンテキストファイルであるシェルスクリプトでさえbinディレクトリから除外されていましたが、この行もぼやけています。現在、binディレクトリには通常、厳密に「バイナリ」であるかどうかに関係なく、あらゆる種類の実行可能ファイルが含まれています。

脚注と余談：

1. SVR4より前のユーザー管理ツールの基本的な性質により、このHOME=/usr/$NAMEスキームはデフォルトとしてソフトウェアツールによって実施されるのではなく、単に慣例として文書化されていました。

   これは、「AT＆T Unix System Vリリース3.2システム管理者ガイド」の4-8ページにあります。ここでは、AT＆Tが、/usr/$NAMESVR4がリリースされる前のUNIXの最後のメジャーバージョンで古いスキームを推奨しています。

   古いUNIXシステムでは、システム管理者がより意味のある別のスキームを選択することはかなり一般的でした。人々は人々であり、それは多くの異なるスキームが発明されたことを意味しました。

   以前に出会ったスキームの1つ/home/$NAMEが標準になりました/u/$NAME。

   1990年代初頭に使用した別のシステムには非常に多くのユーザーがいたため、すべてのホームディレクトリを単一の物理ボリュームに収めることができなかったため、思い出すよう/u1/$NAMEに/u2/$NAME、などのスキームを使用しました。ホームディレクトリがどのディスクになったかは、アカウントが作成された時点でどのディスクにスペースがあったかということです。

2. 起動Cmd-S中に押し続けると、macOSボックスをシングルユーザーモードで起動できます。画面が黒くなり、明るい灰色のテキストが表示されたら放します。ターミナルの下で実行するようなものですが、GUIがまだ開始されていないため、画面全体を引き継ぎます。

   注意してください、あなたはとして実行していrootます。

   シングルユーザールートプロンプトで「exit」と入力して、シングルユーザーモードを終了し、マルチユーザーGUIモードでの起動を続けます。

3. 重要なシングルユーザーモードのファイルを保持していないように見える Unixy OS /usrは、実際には最近そうしないかもしれません。/usrZFSボリュームに移動して、FreeBSD 9ボックスをブート不能にしたことがあります。ZFS-on-root機能は、FreeBSD 10がCatch 22を作成するまで着陸しなかったことを忘れていました。OSは/usr、マウントするためにファイルが必要でした/usr！

   それは十分に悪いことでしたが、もしFreeBSD 9がまだシングルユーザーブートを排除していたら、/usrそれを修正することができました。/usrマウントできないためにシングルユーザーモードでも起動しないため、明らかにその伝統が何らかの形で違反されていました。そのシステムを再びバックアップするには、レスキューCDから起動する必要がありました。

4. これは、取得する場所でもあり/usr/shareます。異なるプロセッサタイプのUnixボックス間でも共有できるファイルを分離します。通常、テキストファイル：manページ、辞書など。

5. 「X11R6」は、この規約が普及した当時のLinux GUIを支えるX Window Systemのバージョンを指していました。Linuxシステムは一般に、X11R6がX.Orgに置き換えられた頃にGUIソフトウェアの分離を停止しました。

6. オリジナルのUnixシステムは、それらのコアシェルスクリプト/etcを、の真のバイナリと混同しないようにするために保持していました/bin。

一般的な構造関連の質問については、ウィキペディアを参照することをお勧めします。基本をカバーします。

ただし、質問に直接回答するには：

• / usrは、大まかに言って、重要ではないシステムライブラリと実行可能ファイルです。
• / usr / localは、大まかに言って、非システムライブラリと実行可能ファイル用です

これが、2つの間で同様の構造を見つける傾向がある理由です。/ usr / {、local /} {bin、sbin、lib}。シェルが初めてなので、{}の付いたビットはシェル拡張です。実行してみてください

ls -ld /usr/{,local/}{bin,sbin,lib}

ローカルシェルからそれがどのように機能するかを確認してください。

/usr/local/bin は、最新のMac OS（そのBSDベース）のUNIX風のルートを示しています。

• 「usr」は、UNIXシステムリソースを表します。これは、システムプログラムとライブラリが保存される場所です。
• 「ローカル」は、標準ディストリビューションに付属していないリソースを表し、通常、サイトごとにコンパイルおよび保守されます。
• 「bin」は、バイナリコンパイル済み実行可能ファイルを表します。

UNIXからLinuxおよびBSDへの初期の実装以来、これは変化していますが、慣習は残っています。現在は、/usr/bin「メイン」またはコアプログラムおよびライブラリ用で/usr/local/binあり、アドオンおよび非クリティカルなプログラムおよびライブラリ用です。

/usr/local/bin は、実行ファイル、特にオープンソースファイルの最も一般的なデフォルトの場所です。

しかし、Unixシステムで/usrは、オペレーティングシステムに属するファイルの階層を含めるために90年代前半に標準化され、そのOSを使用する複数のシステムで共有できるため、これは間違いなく悪い選択です。

これらのファイルは静的であるため、/usrファイルシステムは読み取り専用でマウントできます。/usr/local設計上、ローカルではないため共有されないため、この標準を無効にしているため、ローカルコンパイルを許可するには読み取り/書き込みが必要であり、オペレーティングシステムの一部ではありません。/opt/local代わりに選ばれなかったような残念な...

/usr/localMathematicaなど、インストールする可能性のある商用プログラムに使用することをお勧めします。セットアップ時に独自のパーティションに配置します。OSをアップグレードするとき、このパーティションは邪魔されず、その内容を再インストールする必要はありません。したがって、OSのアップグレード間で保持したいものに使用します。

それとは別に、/homeこの理由からも必ず独自のパーティションを用意してください。

この回答も役立ちます。

/ usr / local

背後/usr/localにある元のアイデアは、以外のすべてのマシンに個別の（「ローカル」）「/ usr」ディレクトリを置く/usrことでした。の構造をコピーし/usrます。

最近で/usr/localは、自己コンパイルまたはサードパーティのプログラムを保持するのに適した場所として広く認識されています。/usr/local階層は、ソフトウェアをローカルにインストールし、システム管理者が使用するためのものです。システムソフトウェアの更新時に上書きされないようにする必要があります。

ホストのグループ間で共有されているが、では見つからないプログラムやデータに使用される場合があります/usr。ローカルでインストールされたソフトウェアは、でソフトウェアを置換またはアップグレードするためにインストールされている/usr/local場合を/usr除き、内部に配置する必要があります/usr。