アカウント名:
パスワード:
それとも、新FHSを提案している?
基本的にはルート直下の/bin, /sbinについては両方ともルートパーティションのみのmountで使用できるよう, スタティックリンクにしておく物がほとんどです. (FreeBSD4.8では/bin下ではrmailのみがダイナミックリンクでした)
現在ではbinは一般ユーザでも使用する物, sbinは原則的には管理者のみが使用する物という感じみたいです. これにより, PATHを切った際に一般ユーザが不要な管理コマンドを見に行かなくする, といった管理上の利便性があると思います.
というか、
ちゃんと読んでないでしょ?
これは素晴らしいアイデアだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
FHS (スコア:0)
それとも、新FHSを提案している?
Re:FHS (スコア:1)
Re:FHS (スコア:1, 興味深い)
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
というようにunixの実行ファイルは点在しています。
/におくファイルを厳選して最小の構成をつくり別のパーティションとしておけば、
最悪の事態でもアンマウントしてfsck可能ということが最大の利点だと思います。
でも、KNOPPIXのようなCD bootするディストリビューションがある現在、
上のようなことはメリットなんでしょうか。
むしろ各々のプログラムがどのディレクトリに入ることが出来るかということは、
/binには最年長の歴史を持つ直系御三家や貴族プログラム、
/usr/binには多くの人に広く認められた譜代プログラム
/usr/local/binには人気はあっても名門出身ではない外様プログラム
/usr/local/プロジェクト名/bin/ デビュー直後のプログラム
というような階級づけで分けているのではないかと考えたりします。
例えばperlとかrubyは外様と譜代にディストリビューションによって評価が分かれるところです。
apacheは最初、/usr/local/binにも入れてもらえず最近になって
/usr/local/apache/binから/usr/sbinへの進入を許されました。
sbin関係ではumountが必要なディスクの修復プログラム、特にundeleteなんかは
/sbinに入るべきだと思いますが。
というわけで、思い切った見直しをするのは悪くないと思います。各スクリプトの先頭の #!
を書き直すのが面倒でなければということですが。
Re:FHS (スコア:1)
Re:FHS (スコア:1)
基本的にはルート直下の/bin, /sbinについては両方ともルートパーティションのみのmountで使用できるよう, スタティックリンクにしておく物がほとんどです. (FreeBSD4.8では/bin下ではrmailのみがダイナミックリンクでした)
現在ではbinは一般ユーザでも使用する物, sbinは原則的には管理者のみが使用する物という感じみたいです. これにより, PATHを切った際に一般ユーザが不要な管理コマンドを見に行かなくする, といった管理上の利便性があると思います.
static (スコア:0)
sbin のみが、スタティックリンクだと思ってましたよ。
sbinのsはそういう意味だと教えてもらった記憶があるので・・・
# 実際、Solarisでは /bin,/usr/bin は同一ですし
Re:FHS (スコア:1, 参考になる)
あとは /bin も /sbin も dynamic です。
Re:FHS (スコア:0)
Re:FHS (スコア:0)
> /usr/local/apache/binから/usr/sbinへの進入を許されました。
それは "configure" のprefix等パラメーター次第で
apacheをコンパイルするユーザーの考えによって異なる話ですね。
貴殿は最近になって "/usr/sbin" に変えたのかも知れませんが
まだ "/usr/local/apache/bin" のままの人もいますし、
最近どころかapacheが出たころからすでに "/usr/sbin" に入れることは可能
Re:FHS (スコア:0)
というか、そこまでやる人はディストリビューションに頼らないので
好きにしてもらっていいです。
たとえば、会社や学校で何か便利なスクリプトを書いたとき、
ディストリビューションやバージョンの違う他人のマシンでは
走らない。あるいは、軽い気持ちでプレゼントしたcron起動の
バッチプログラムが、パスの調整に一苦労ということはないですか。
「ディストリビューションを統一しろ」ってよく言
Re:FHS (スコア:0)
というか、
ちゃんと読んでないでしょ?
Re:FHS (スコア:0)
> 先頭の #!
> を書き直すのが面倒でなければということですが。
面倒なので
#!/usr/bin/env perl
とかしてますが…
Re:FHS (スコア:0)
これは素晴らしいアイデアだ。
この問題に苦しむ全国37700人の方に教えてあげたい [google.co.jp] と、思ったのですが、 envは必ず/usr/binに存在するのでしょうか。
Re:FHS (スコア:1)
とか書くと,
/usr/bin/env: perl -T: No such file or directory.
と怒られます。
Re:FHS (スコア:0)
もちろん、そこまで考えていません :-)
が、まぁ、スクリプト処理毎にいちいち手配してまわるより env だけ面倒見ればよい、とまとめられるところを汲んで欲しいかなぁ、という感じですね。
Re:FHS (スコア:0)
というか、
ちゃんと読んでないでしょ?
Re:FHS (スコア:0)
Re:FHS (スコア:0)
つまりはそういうことなんですよ。/usr/binに入れてよい
プログラムとか、誰が決めたのでしょうか。
こういった暗黙の分類みたいなものがあるおかげで、新参の
プログラムは機能的に優れていても、なかなか使ってもらえない
一因かなと。
シンボリックリンクもshならいいんですが perlとかは
/usr/bin/perl派と
Re:FHS (スコア:0)
Re:FHS (スコア:3, おもしろおかしい)
/Linux2.24/system32/vmlinuz
/Program files/Emacs21.3/bin/
/Documents and Settings/Default User/My Documents/
/LNTemp
(以下略)
# 適当にID
Re:FHS (スコア:1)
# /usr/local/bin/w3m.exe /usr/home/g7/bookmarks/slash\ dot\ japan.url なのでG7
Re:FHS(オフトピ) (スコア:0)
# こういうときID持ってないと不便だなぁ。
# 取ろうかなぁ。
### ID持ってないのでAC ###
Re:FHS(オフトピ) (スコア:0)
Re:FHS (スコア:0)
案外実用性たかいかも。
「ディレクトリの構造まで変えられるほど柔軟です」
Re:FHS (スコア:0)