ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
UNIXやPOSIX準拠OS(Linux等)で、コンピューター利用者全員で用いる、基本的なバイナリファイル(実行ファイルなど)を格納するディレクトリ。
そもそもなぜ、/binと/usr/binで分けるようになったのか。
それは、インストールやシステム修復時に使うminirootのようなシングルユーザーモードで必要なものをルートパーティションに置いたためで、このルートパーティションの容量は必要最小限(古くはフロッピーディスクの容量)で済むように工夫されてきた。
そこで、必須のものを/bin、それ以外を/usr/binに置くようになった。
もちろんルートパーティションと/usrパーティションを同一にすることも可能だが、現実には、そのような運用はあまりされていない。
ルートパーティションと/usrパーティションの区別を無くすという考え方は決して新しいものではなく、GNU Hurdも以前から実施していた。
但しGNU Hurdの場合、/usr/bin、/usr/sbin、/usr/libを廃止して、各々、/bin、/sbin、/libに統一していた。
/usrをルートパーティションに置くという方針と結果はFedoraと同じだが、統合する場所が違うのが、恐らく思想の違いなのだろう。
単なる利用者の視点からすると、統合するなら、GNU Hurdの方式の方が素直に見えるが、Fedoraはなぜ逆にしたのか、定かではない。
/bin/sh は、シェルである。
元々は元祖シェル(Bourne Shell)であったが、現在は使用中のシェルへのシンボリックリンクであることが多い。
多くのLinuxディストリビューションでは、/bin/sh はbash(/bin/bash)へのシンボリックリンクである。一方でUbuntuの場合、/bin/shがシンボリックリンクなのは他のLinuxディストリビューションと同じだが、そのリンク先はLinuxで人気のbashではなく、dash(/bin/dash)となっている。dashはashの派生であり、元祖シェルに近い機能を持つ。
世の中には、bashの機能を用いていながら、シェルスクリプトの先頭に #!/bin/sh などと書いて済ませる不届き者が多くいる。/bin/sh のリンク先がbashであるなら正常動作するが、さもなくば正常に動作しない。このためdashを使うUbuntuではシェルスクリプトが正常動作しないという「問題」が発生した。
最近のLinuxや、FreeBSD 6.1ではtcshが採用されており、/bin/tcshにある。
同じBSDでも、NetBSD 4.0は標準がcshである。NetBSDの場合、packageを使ってインストールするのが一般的なので、この場合、本体は/usr/pkg/bin/tcshとなり、/bin/tcshはこの本体へのシンボリックリンクとなる。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます