FreeBSDでのifconfigリファクタリング作業 38
ストーリー by wakatono
身近なコマンドの意外な一面 部門より
身近なコマンドの意外な一面 部門より
ozuma 曰く、 "BSDForums.orgの記事によると、Bruce SimpsonによるFreeBSDでのifconfig(8)リファクタリング作業の一環として、与えるべきオプションとパラメータの構造を記述したYACC文法ファイルが公開されている。Bruce氏は「ifconfigはあまりに強大なユーティリティとなってしまい、現在想定される全てのオプションの組み合わせを理解する助けとして」YACC文法ファイルを作成したという。
また、文法構造のダイアグラムもPDFファイルとして公開されており、視覚的にも構造が分かるようになっている。"
まずは身近な使い方がどれかというのを見ていって、それから他の使い方を見ていくとわかりやすいかも。
複雑さの原因 (スコア:2, 参考になる)
ifconfigのパラメータが複雑になってしまった原因なんですが, ネットワークモデルにおける複数のレイヤを単一のコマンドでコントロールしようとしているからではないでしょうか? 確かにインターフェイス周りの設定が1箇所で出来るというのは, それなりの利点が有るわけなんですが.
私がそれを思ったのは無線LANの設定をやっていた時で, 最初は無線LANの設定用コマンドwicontrolで無線LAN固有の設定を行った後, ifconfigで上位のネットワーク構造の設定を行おうとしました. それがifconfigを調べてみたら, ほとんどの無線LAN周りの設定がifconfigで出来てしまい, 結局wicontrolの出る幕は無くなってしまいました. これにより設定ファイルの記述は簡潔になったのですが, 個々のオプションが使用しているハードに影響を及ぼすかどうか判断が必要で, ちょいとばかし嫌な気分になったのは確かです.
Re:複雑さの原因 (スコア:1)
逆に言えば，インターフェースの設定には ifconfig を使うんだ!!
と言い切れる状態の方がいじる方としては楽かな～? って思います．
しょっちゅう man を見る事になるんですが，日本語マニュアルだってあるし，英語マニュアルだって頑張れば何とか読めるので，
個人的には，ifconfig 一発でインターフェースの設定が終わる事は良いことだと思います．
# もちろん，その後に /etc/rc.conf へ反映させますが．
------------------------
いつかきちんと仕上げよう
Re:複雑さの原因 (スコア:2, すばらしい洞察)
Re:複雑さの原因 (スコア:0)
要するに踏台、てか。
実はそれほど使わない? (スコア:1)
頻繁に変えるものでもないので、アドレスやaliasの設定は、インストールした時にrc.confに書いて終わりでした。
一番使うのは、10Baseで間違って認識された時でしょうか(w
Re:一番使うのは (スコア:1)
既に何人が利用してるのかわからないファイルサーバーがあって
2GB/DayのスピードでHDD残量が減っていってます・・・
ファイル名みると XX向けXX仕様書「日付」.doc の日付違いなんてのがずらぁ～っと並んでる・・・
修正前のファイルは2-3世代程度を残して消してほしいものです（TT
（頼むからWordなどの「履歴機能」使ってくれ！
って使い方わかってる人がいない。使えばかなり節約できるはずなんだけど）
Re:一番使うのは (スコア:1)
９月を過ぎた頃に、新しいファイルがお目見えしなくなったので、やれやれと思っていたら、10月分は上の方に．．．
そうか、名前順に並べていると、そうなるか！という事態もあったりして。
古くてほとんど必要の無いものは、一階層落とせよ！と思うのだけど、直りませんね。(無くて七癖)
Re:一番使うのは (スコア:0)
Re:一番使うのは (スコア:0)
ファイルの履歴を保存してしまうバージョン付きファイルシステムにして、何であれ常に上書きでも必ず好きな時点に戻れるという安心感を持ってもらうのがお勧め。
あとはディスクが足りなくなったら履歴の（古い｜まったくアクセスされない）方から勝手にオフラインストレージに移してしまう、と。
Re:実はそれほど使わない? (スコア:1)
でもまぁ、動作確認した後はスクリプトファイルに書いて終了だけど。
Re:実はそれほど使わない? (スコア:1)
ん。ってか、リモートから叩くにはチョイと危険な気がしますよね（笑。
しかし、
「csh(builtin),sed,ls,ifconfig のman は最低限、通読するように」
ってのは、もはや時代じゃない．．．のかなぁ．．．(^-^；
# 各man の、see also を見て、他のman を眺める．．．ってのが
# その後の成長にかかってくるのですが
# そういう意味で、最初に鍛える部分は
# vi/less (nethack )の操作であると、信じています。
現在でも、PC-UNIX を理解する足がかりとして
必要、最低限な気がするんですけどね。
# 歳かなぁ・・・（笑。
私がifconfig と訊いて想い起こすのは
このページでしょうか。 [sanpei.org]
当時(FreeBSD2.x 頃？)は、有益すぎる情報 [sanpei.org]に
頭が下がる思いでした。
# モチロン、今でも感謝しています（笑。
Re:実はそれほど使わない? (スコア:1, おもしろおかしい)
> ってのは、もはや時代じゃない．．．のかなぁ．．．(^-^；
「man: google使えよ [namazu.org]」ということで（ｗ
Re:実はそれほど使わない? (スコア:0)
> 必要、最低限な気がするんですけどね。
「PC-UNIXを理解する」ことを目的とする人が減ったんでしょう。
ただの手段であって目的ではない。
ご自身仰るとおり、お年寄りさんですね。
ちなみに私は
> 「cs
自分のマシンでは (スコア:1)
$man man
/usr/bin/groff: can't find `DESC' file
/usr/bin/groff:fatal error: invalid device `nippon'
#最低限通読すべきなのはgroff
Re:自分のマシンでは (スコア:1)
マニュアルが圧縮されている事があるんで、
gunzip？
PCにECC Registeredメモリの利用を推奨します。
Re:実はそれほど使わない? (スコア:1)
なんて言ってられたのは古き良き時代だけですね。 マニュアルの項目は増えるし、新人の根気はなくなるし。
Re:実はそれほど使わない? (スコア:1)
> > 「csh(builtin),sed,ls,ifconfig の man は最低限、通読するように」
> こんなこと言う人はじめてみました。
同じく。必要なモノは man -k と SEE ALSO で事足りますから。
とにかく man を読めとは言われましたけどね。おかげでまず自分で調べるという
当り前の癖は付きました。
// まぁイチイチ man 見るよりは通読して覚えた方がいいと思いますけどね。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
kameで (スコア:0)
途方に暮れたことがあります。
gdbで追っていくと、confファイルを読んで
プログラム内のtmpリストに追加しているように読める。
そして、ちょうどメンバ数2までの制限が
かかってることまではわかったが、改造出来ない・・・。
そしてまわりを見回しても、C+スクリプト言語(sed,awk,perl,...)
が出来る人はいるが、yaccは0。
マイナーなんですかね。
構文解析に向いてて便利そうというのはわかったんですが。
#yacc(ヤック)を"やっこ"だとずっと思ってたのでAC
#やっこの方がかっこいいはず・・・。
Re:kameで (スコア:1, すばらしい洞察)
yacc の難解さに嫌気がさした人々が、富豪的に XML を使ったりするんでしょうね。
コメントの記法やら継続行の記法やら特殊文字のエスケープの方法やら、アプリケーション毎に違うのは勘弁…
ifconfig + libxml (スコア:2, すばらしい洞察)
とはいえこのトピックに沿って言うなら /sbin/ifconfig に libxml が組み込まれるのも勘弁だなあ。
フロッピーで起動できなくなっちゃうよ。
Re:ifconfig + libxml (スコア:1)
YAML for config (Re:ifconfig + libxml) (スコア:0)
ヤック (スコア:0)
Re:ヤック (スコア:0)
Re:ヤック (スコア:1)
yaccは便利 (スコア:0)
BNFさえ理解できれば、後はそれ程難しくないですね。お約束レベルの事をいくつか憶えればおしまい。
BNFわからなければRFCも読めませんから当然みんな判っ
Re:yaccは便利 (スコア:3, 参考になる)
昔話をすると爺くさくてやなんだけど、僕は昔kmyaccというクローンを実装しまして、CP/M(80の方)上で動かしてました。Cの構文程度ならちゃんと処理できましたよ。
yaccって、人が思ってるほどメモリ食うもんじゃないです。生成されるテーブルもかなり圧縮されてますし。
ただし、「それ程難しくない」とは言えないなあ。このifconfigの構文程度なら簡単でしょうけど。
実際、conflictが出まくると頭かかえちゃいます。
Re:yaccは便利 (スコア:1)
昔ずいぶんお世話になりました。どうもありがとうございます。
ちょっとしたインタプリタ風ツールの入力解析やら#446560のACの方同様の設定ファイルの解析やら程度にしか使ってませんでしたが、私みたいに頭の出来のよろしくない奴が手で書くぐらいだったらyaccに吐かせたほうが効率のいいものができたような気がしてました。
（パーサの類を手書きすると状態遷移が多すぎてわけがわからなくなって、実行時間やメモリの話以前に結局いつになっても物が出来上がらないからだ、というオチは伏せておきます…）
ついでに言うと、そんな程度のものでもなかなかconflictの解決ができずに頭をかかえちゃったりして。「それ程難しくない」といえる人がうらやましい…
まあ、最初の投稿者の方の話じゃないですが、使っている人自体少ないし使いこなしている人はさらに少ないというのは当たっているかなと思います。
それはさておき、今手元で動いてるFreeBSD5.1のifconfigのマニュアルを見ると、「こんなの手で書きたくない！」とは思いますね。yaccを使おうというのは正しい選択かなと。
Re:yaccは便利 (スコア:1)
bisonやFreeBSDに付属のyaccに比べて、出力するコードがコンパクトだし、
liby.a が要らないのがUNIX/Win(BorlandC++)でコードを共用するのに便利なもので。
Re:yaccは便利 (スコア:2, 参考になる)
最近C++のboost::spirit [boost.org]という構文パーサにはまっております。
非常に良く出来た（変態的な）ライブラリで、yaccや組み込みSQLのような別の処理系や
プリプロセッサを使わず、生のC++コードにEBNFもどきの文法とアクションを直接埋め込んで
構文・字句解析ができるようになっています。
yaccとは一味違うEBNFを採用していること、無理やり感のある独特な構文表記、
Javaに押されぎみでマイナー感が出てきたC++と、いろいろ絡み合って、正にアレゲな感じです。
複雑な構文を処理するならyacc/flex、そうでないならspiritと使い分けたいのですが、
もともと少ないC++プログラマで、さらにEBNFが理解できる人があまりいないのが玉に傷。
興味ある方は選択肢のひとつとして調べてみると良いことがあるかもないかも。
#yacc++とかはおいかけてないので、よく分かりません
Re:yaccは便利 (スコア:2, 参考になる)
＃まだ途中みたいですが…
Re:yaccは便利 (スコア:0)
使ってみてもよさそうだけどGCCと組み合わせたときがどうなるか…
Re:yaccは便利 (スコア:2, 参考になる)
C++ + templateなんで、かなりCPUを消費します。
まだ小規模なとこにしか使っておりませんが、数十～百行程度
のEBNF構文定義であれば最近のPCでストレスなくコンパイル
できます、が、それ以上の規模になるとどうなるかわかりません。
#VC7.1+P4 3GHzなんで、gccを使う場合参考にならないかも
シンボルテーブルを食い尽くすらしく、デバッグ用のオプションを
少し弱めに変更しないとうまくリンクできませんでした。
他に気づいた点で言うと、yaccで生成したものと比べて実行時に
スタックを消費する傾向があるので、その辺も注意したほうがよいでしょう。
等価な文法を食わせて統計を取ってみると面白そうですね。
Re:yaccは便利 (スコア:0)
しかしこのストーリーの閑散とした状況(コメント数19)を見ると、そうじゃないんでしょうね。/.Jって、"News for Nerds, Stuff that matter"なんてごたいそうなこと
Re:yaccは便利 (スコア:1)
knuth博士の博士論文って、LR文法じゃありませんでしたか？
Re:yaccは便利 (スコア:1)
Perl::RecDescent [ibm.com]にせよ、JavaCC [ibm.com]にせよ。
JavaCC に関しては必要に応じて先読みトークンの数を増やせるという仕様があるので、
LALR を使うまでもないことのほうが多いのかもしれませんが。
Re:yaccは便利 (スコア:0)