GLOBALの話をするよっ。このGLOBALさん、emacsからのタグジャンプがetagsより賢いのがお気に入りで(特に同名関数がたくさんあるばあい、etags.elは問答無用で最初にマッチした関数にジャンプするので全然役に立たない)長いこと愛用してる。押して「イラッ」とかしてた。クセになってるんだもんで、ソース見たら案外拡張が簡単そうだったのでさくっと対応してみた。2時間いらなかったんじゃないかな。みながら、CVSからチェックアウトする。ftpからダウンロードしてはいけない。入ってなくて二度手間だ。Linuxでは普通にビルドするとgtags実行時に毎回以下の警告がでて非常にうっとうしい。動くかどうかをconfigure中で実際にsortコマンド叩いてみて確認する方法。wordたぶん、gperfの制限だと思うけどglobalは予約語リストに書いた名前がそのままCのマクロ名の一部として転用されるため"="とか"?"とかみたいな記号が使えない。予約語に登録するはめになったけど多分大過なかろう。いうのでハマるのは凝ったことしたい人だけだ。closetoken();}あとは適当にMakefileやらparser.cのlang_switchやらを適当に追記していくだけ。ソース入れといたんで興味ある人はどぞ。あ、aliasの対応わすれてることに今気づいた。」のルールは難しそうだったので未実装。parserのgenericなルートを書き換えずにruby用のタグを作るときだけHook仕込むいい方法が思いつかんかった。globalには任意のコマンドを呼び出せるプラグイン機構があるので頑張ればripperベースのまっとうなrubyパーサを呼び出すこともできなくもないような気がした。ripperを勉強するのがメドイのでやらなかったが。コマンドの動作が劇的に開眼している。total圧倒的じゃないか我が軍は!これに気づいただけでも、今回の作業をした価値があったよ。2011daemonについてRubyのconfigure.inには以下のように、*BSD以外は強制的にdaemon(3)がないと判定させるあやしげなロジックがある。後に一般化されている。困ったことに理由はまったく記載されていない。腐ってるという扱いにした理由も書いてないんだけど。本当かどうか分からないがある人から、Linuxのdaemon(3)は本来二回forkが必要なところを一回しかforkしてないので腐ってる。それが原因ではないかと教えて貰ったhttps://www.codeblog.org/blog/akr/200511.htmlほー。こんな話があったのか。0;}ためしに、Solarisのlibcのdaemonを見てみると・・・・おお、たしかに二回forkしとる。referenceでサーチしていて分かったのだが、OpenSolarisの場合付属コマンドが*BSDからもってきたdaemon()を自分で抱えてるケースがいっぱいあって、libcだけ真面目に二回forkしていても現実的には全然安心できないというのがトホホである。いうわけで、Linuxのlibcのdaemonはいまいちイケテないってことと、SolarisのlibcはまともだけどSolarisのユーザランドのコマンドはまともとは限らないって事が分かった。「Amazonライブリンク」は提供を終了しました。