Unix 辞書ソフト総合スレッド 第二版
Unixで辞書ソフトを活用するための情報交換スレッドです。 前スレ: Unix 辞書ソフト総合スレッド http://pc5.2ch.net/test/read.cgi/unix/1005185290/ リンク等は>>2-3 >>250 (eval-after-load "lookup-vse" '(defun lookup-arrange-gaijis (entry) (let* ((case-fold-search t) (dictionary (lookup-entry-dictionary entry)) (regexp (lookup-dictionary-option dictionary ':gaiji-regexp t))) (while (re-search-forward regexp nil t) (delete-region (match-beginning 0) (match-end 0)))))) おおぅ、いけました! ありがとうございます。 遅レスすいません。 なんか最近 xyaku でしばしば訳がポップアップされなかったりするけど うちだけ? xyaku 1.4.0 の src/exec.c の exec_addin_cmd にある /* Use select() and SIGCHLD signal handler. In order to deal with the case the child puts no output to stdout. In that case, it doesn't come back from read(). */ child_die = 0; signal(SIGCHLD, child_die_handler); に関連した処理を消したら直った。 これのせいで addin の出力を全部読む前に処理をぬけてた。 消してもコメントに書いてあるようなことは起こらないけどなあ。よくわからん。 ターミナルで $ kensaku ほげ で ebzip された辞書を読んで 結果を整形表示してくれるものありませんか? >>262 http://www.tanu.org/ ~sakane/doc/public/howto-ndtp.html#ndtpc >>263 ,264 ども.実はリナザウで,それほど頻繁に辞書を引くことはないのですが, たまに使うときに zten を立ち上げるのが面倒なので, 常駐してるターミナルから直接引けるものがあればと思って質問しました. ndtpc を使うために ndtpd を常駐させるなら zten を常駐させます. 無いようなら RubyEB を使って書いてみようと思います. >>265 emacs常駐してんだったらlookup。じゃなきゃeblook。 eblookのラッパを自分で書くのが一番簡単かな。 >>267 eblookはコマンドを標準入力から読むので、リダイレクトで行けますね。 (eblook.vimでは一時ファイルにsearchコマンド等を書いてリダイレクトしてます) ~/.eblookrcにbookとselectが書いてあることを想定すると、 こんな感じで。(これだと最初のエントリしか表示できないけど) #!/bin/sh echo |eblook <<EOF search $1 content 1 EOF >>268 書ける人なのね。 #!/usr/bin/expect -- log_user 0 spawn -noecho eblook /home/foo/dict/readers send "select 1\r" send "search [lindex $argv 0]\r" expect -re "(\[0-9a-f]*:\[0-9a-f]*)" { send "content $expect_out(0,string)\r" send "quit\r" } expect "content" expect "quit" interact eof exit あとはreference追うなど随意に。 >>269 お、expectですか。 たしかにeblookのようにインタラクティブな操作を想定しているものは expectの方が便利そうですね。 シェルスクリプトだとeblookをsearchとcontentで2回は動かさないといけないので。 #!/bin/sh echo "search $1" | eblook | sed -e 's/^eblook> //' \ | awk '/^ *[0-9]*\./{print "content " $2}' | eblook >>265 読めよ。なんだよ、「事足りる」って 馬鹿? >>268 ,269 リダイレクトで eblook を使えるとは知りませんでした. リナザウに expect がなくて, 入れるには tcl のインストールとか面倒なので, 多少,効率が悪くなってもシェルスクリプトの方法を採ろうと思います. どうもありがとうございました. emacs + lookupで『ジーニアス大英和』を読めている方いますか? うちでは語源の部分しか出てこないのですが、どうしてでしょう? >>280 ありがとうございます! appendixはemacs -nwで使うとき以外は不要なんだと 早合点してました。 あとは大辞泉をlookupからひけるようにしてもらえれば しあわせなんだけどなあ。 持ってる人が少ないのかな。 (daijisenコマンドはつかってます) こういう出力なんだけどなあ > daijisen dougi どう‐ぎ【同義】 意味が同じであること。同じ意義。 どう‐ぎ【胴木・△筒木】 〔1〕太い木材。丸太(まるた)。〔2〕城壁の上に備えておいて、敵が攻め寄 せてきたときに落とす丸太。どうづき。 どう‐ぎ【胴着・胴△衣】 〔1〕和服用の防寒着で、長着とジュバンの間に着る綿入れ。胴服。どうい。《 季 冬》〔2〕人体の胴にまとうもの。どうい。「救命―」 どう‐ぎ【動議】 会議中に予定議案以外の議題を議員が提出すること。また、その議題。「緊急― 」 どう‐ぎ【道義】ダウ‐ 人のふみ行うべき正しい道。道理。「―にもとる行為」「―的責任」 ebviewは0.3.6より0.2.1の方が何かとデキが良いと思うのは俺だけ? 言わないだけでなく、そこからフォークしようとする人もいない。 衰え果てたフリーソフトウェア界のなれの果てさ…… 0.2.1で十分使えるから別にforkする理由もないような。 forkするならGTK2化のやり直しという実に無駄な作業が待っているし。 もしかしたら、GTK2化すると否応なくああなってしまうのではなかろうか 久々に使おうと思って、Fedora core 2で環境を構築したら、 辞書のappendixが使えないのです。(なしでは使えています。) letmesee.confの@dictlistは以下の通りです。 @dictlist = [ "/usr/share/dict/kojien5", ["/usr/share/dict/genius","/usr/share/dict/genius2-1.1"] letmesee.confの表記に誤りがあるようなんだけど。 以下のエラーが出てきてしまいます。 cannot convert Array into String (TypeError) ./letmesee.rb:66:in `bind' ./letmesee.rb:66:in `initialize' ./letmesee.rb:64:in `each' ./letmesee.rb:64:in `initialize' /var/www/html/letmesee/index.rb:13:in `new' /var/www/html/letmesee/index.rb:13 環境はFC2+eb-4.13+rubyeb-2.6+letmesee-1.1rc3です。 何が原因でしょうか 修正 letmesee.confの@dictlistは以下の通りです。 @dictlist = [ "/usr/share/dict/kojien5", ["/usr/share/dict/genius","/usr/share/dict/genius2-1.1"] ] appendix って使ったことないからよくわからないけど、 letmesee で使えるの? あと、とりあえず letmesee-1.1rc3 より letmesee-1.1 の方が新しいから、 そっちでやってみたら。 すいません。 letmeseeの最新版をCVSからとってきたら、正常に動作いたし真sちあ。 >>297 > あと、とりあえず letmesee-1.1rc3 より letmesee-1.1 の方が新しいから、 > そっちでやってみたら。 letmesee-1.1でも対応してないのですよ。 letmesee.conf.sampleにappendixに関する表記がないので、 CVS版だと表記があるので大丈夫なのでした。 こういうのは作者の方に連絡すれば、対応していただけるのでしょうかね。 とりあえず、ご迷惑おかけしました。 >>299 CVS版で対応してるなら, 無理にリリースしてもらわなくてもいいのでは? 俺は ndtpd で辞書を一元管理したくて forest 使ってる. rdic、正規表現検索の部分だけでも無理にrubyでやらずにgrepか何かにまかせれば ぐんと軽快になると思うんだけど、だめなのかな。 考えてみりゃ、単にgrep|lessすればいいんだから 別にrdicを通す必要もないか。 letmesee で英単語検索するときに stemming するラッパー書いた。perl で。 これと firefox の superdragandgo でずいぶん 英文読むのが楽になった。 debian にあった libtext-english-perl という Porter stem アルゴリズムのライブラリを使って、 cgi で単語を受け取って、stem して、 letmesee の url で refresh しただけというやつです。 ruby がわからんので perl -> ruby という皮肉な受け渡しになってます。 なんかRubyスレの自動生成荒らし文みたいだなぁ。 >>301 > rdic、正規表現検索の部分だけでも無理にrubyでやらずにgrepか何かにまかせれば > ぐんと軽快になると思うんだけど、だめなのかな。 うひ……うひょほほほ……うぁわは なんでここは過疎化しているのだろう?こんなに便利なツール紹介してるのに。不思議。 使う辞書もソフトも安定してくると、 日常的に使ってても話題がないよ。 EB-lab はいい仕事をしたな。 これがあるから、この板でわざわざ相談するようなことはほとんど出て来ない。 使うだけ。 独自仕様の横行は嘆かわしいが、これはどうにもならんし。 あ、なるほど。そう言われてみればまったく不満はないですね。EPWING対応の買ってくればまず動くし。 革命的な事でも起こらない限り盛り上がらないのも仕方ないのか・・・ パソコンで辞書ってほとんど必須というか、 これこそコンピュータの利点だと思うんだけど、 意外となくても困らない人多いみたいね。 unix ユーザの何割くらいが辞書使ってるんだろ。 unixユーザ≠unixをクライアントとして使う人 であることに留意。 その方面で盛り上げたいなら犬板が向いているぞよ。 unixユーザ=unixをクライアントとして使う人。 クライアントが何を意味しているか知らんが。 俺はプログラミングとかで英文を読む時しか辞書使わないな。 職種や趣味によっては辞書を引かない人も多いと思う。 まあunixユーザは(Windowsとかより)英文を読む機会が多そうな気がするから、 わりかし必須かもしれないけど。 現代用語の基礎知識2005もハードディスクに突っ込むだけでlookupで使えるぜ!ヽ(゜д゜)ノ EPWINGってunicode対応してないの? だから英語以外の外国語辞書に弱いのかな? ウムラウト程度で外字扱いとかはさすがに やばいだろ… EPWINGの規格が定まったのってUnicodeの規格が定まった時期より前じゃないか いやEPWINGって何度も規格拡張なり改定なりされてるじゃん なんで何時までもunicode対応されないのかなと unicode 対応しても労多くして得るところはそれほど多くない。 それぞれの事情によって違うので好ましいと思う向きもあると思うけど 必要性はそれほど無い。 多言語が外字によってでしか扱えないのは辞書フォーマットとして 先が見えてるよ。 なら使わなければいいだろう。文句言うだけなら誰だって出来る。 おまえの糞みたいな脳内仕様を何かしらの形で具現化してからなんか言えよゴミ。 >>331 おまえのも少なくとも同程度にゴミなんですが。 多言語どころか日本のコード体系で表せないものは全てダメなんで、 中国語とか扱おうと思ったら悪夢ですな。 外字になったら表示はできてもコピペできないからどうやって入力したものかと また手がかかるし。 いみじくも>>331 のいうように、EPWINGはもう捨てるのが正解だと思う。 現在のニーズに合わせた辞書形式を統一しようという機運も出そうにないし(ベンダにうまみがない)。 ベンダにメリットが生じるようにさせるには、個々のユーザが 独自規格の辞書を避けて共通規格の辞書を買うように行動する必要があるな。 >>330 >多言語が外字によってでしか扱えないのは辞書フォーマットとして 私は、perlを使って欧米語や日本語で使われている外字に振られたコードを Unicodeに変換するテーブルを作成して、EPWINGのデータを、Unicodeに変 換している。Emailでもコピー&ペーストができる。 いろいろ問題があっても、EPWINGは内部構造が事実上公開されているので、 プログラムが少しできる人間には、とても使いやすい。 アクセント記号や発音記号くらいならそれでもいいけど、 大量の漢字などが相手ではその手の対症療法ではどうにもならないと思うよ >>335 >大量の漢字などが相手ではその手の対症療法ではどうにもならないと思うよ 「大量」というのは、平凡社百科事典で使用されている外字の数かな? 平凡社百科事典は利用者が多いから、(不完全な?)外字変換テーブルは、 出ているのでは? 仮に「外字-->Unicode変換テーブル」を自作するとしても、内部構造が公開され ていないMicrosoftの辞書や百科事典を自己解析して、Unixで使えるようにする労力 (3ヶ月以上かかる?)に比べれば、前者の作業は圧倒的に楽(1週間で終わる!) まあ欠点はあっても共通フォーマットとして認知されてるから 便利だけどね。 何か辞書が出るたびに一週間潰してその辞書にしか使えないテーブル作るか 誰かが公開するのをマダー? (・∀・)っ/凵⌒☆ チソチソ とか言って待つってこと? やっぱり、そういうのじゃ先がないと思うよ。 それに、これってコンテンツ制作側にしてもいちいち 「その辞書にしか使えない外字テーブル」作らなきゃならない ということでもあるから、ますますベンダにはメリットがない。 まあこれは辞書に限らず電子出版全体に関わってくる問題なんだけどね。 >>338 >やっぱり、そういうのじゃ先がないと思うよ。 <先>はなくても、<現在>はある?! 内部構造が公開されていないマイクロソフトなどの他の辞書は、 Unixでは使えないのだから、<現在>すらない。ベンダーも マイクロソフトの辞書の規格で作成することが不可能だから、 ベンダーも同様に<現在>すらない。 >「その辞書にしか使えない外字テーブル」作らなきゃならない Unicodeにある文字を使うのであれば、1つの共通の変換テーブル があればOK。Unicodeにない<外字>を使うには、ベンダーごこに 外字テーブルを作成する必要があるだろう。 いや、新しい規格がいいものでみんな乗っかるなら それは素晴らしいことで、私自身epwingに特に愛着あるわけでは無い。 ただ unicode ということであれば何の解決にもならない。 対症療法の最たるもので、良くなる部分もあるが 辞書を利用する上で現在よりかなり困る部分も出てくる。 (ここら辺はMLや各種論考でも文系の研究者によって挙げられているので 調査、参考にされたし。) もちろんそれらを解決した新規格の策定には反対などしません。 # 現在、私たちのグループではその予備調査となるかもしれない # 調査、研究を地道に行っています。 unicode がしょぼい仕様なのは知ってるけど、 あれで CJK の感じの統合問題とかがなければ かなり理想的なコードだったといえるんでしょうか。 研究を地道にやっている間に世界は独自規格で埋め尽くされていた、 という落ちにならないことを祈ります。 つーかな いい規格があってもそれに乗っかって辞書を発売してくれるかが全てだし 有志でフリーの優れた規格を作って、ツール類も整備しても、 肝心の辞書を有志で作れないから普及しない そういや、wikipediaってDVDにでも焼いて頒布して資金源にとかできんの? 規格普及もそういうところから攻めていけばいいと思うんだけど。 >>345 それいいね。各言語版が入って5000円切ってたら買えるかな。 するとターゲットは世界標準だな 誰か英語に堪能な奴を連れてきて、フリーの辞書規格を 作るプロジェクトを動かさないと タッグを組むならヨーロッパの小さめの国とかがいいぞ 英語圏は文化なんか向こうから来ると思ってるから、 辞書なんかに真剣になる訳がない 普通に英語圏は辞書の重要性は認識してるよ 辞典類を編纂する態度もフランス(のような大国を自称する小国) がとる不遜な態度とは違って結構控え目だし なんにせよEPWINGを規格拡張するなら言語コード拡張以外なにか 思いつく? 結構このスレ見てる人いたんだな。ちょっと安心したよ。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる