▼スレッド
│
└◇206:mutt 1.3xを使いたいのですが．．． [gokko] 02/20 23:09

　└◇213:Re:mutt 1.3xを使いたいのですが．．． [楊志] 02/24 
　　└◇215:Re[2]:mutt 1.3xを使いたいのですが．．． [gokko] 02/25 
　　　└◇221:Re[3]:mutt 1.3xを使いたいのですが．．． [楊志] 02/27 
　　　　└◇231:Re[4]:mutt 1.3xを使いたいのですが．．． [gokko] 02/27 
　　　　　└◇238:Re[5]:mutt 1.3xを使いたいのですが．．． [楊志] 02/28 
　　　　　　└◇239:Re[6]:mutt 1.3xを使いたいのですが．．． [gokko] 02/28 
　　　　　　　└◇250:Re[7]:mutt 1.3xを使いたいのですが．．． [楊志] 03/02 
　　　　　　　　└◇251:Re[8]:mutt 1.3xを使いたいのですが．．． [gokko] 03/02 
　　　　　　　　　└◇269:Re[9]:mutt 1.3x諦めるしかなさそうです [gokko] 03/08 
　　　　　　　　　　├◇270:Re[10]:mutt 1.3x諦めるしかなさそうです [楊志] 03/10 
　　　　　　　　　　└◇274:Re[10]:mutt 1.3x諦めるしかなさそうです [楊志] 03/13 
　　　　　　　　　　　└◇284:Re[11]:mutt 1.3x諦めるしかなさそうです [gokko] 03/15 <

どなたか、「mutt(V1.3x系)＋日本語パッチ版」をCygwin上で
使用可能にされた方、いらっしゃいませんか？
libiconv(static or shared)、slang、mutt+日本語パッチ、
全てmakeは通るのですが、日本語メールのsubject、本文
が表示できません（文字化け。iso-2022-jpがデコード不可？）。
2chあたりでも、一時話題に上ってましたが、解決できません。
何とか、コンソールで使えるMUAとして、muttを使ってみたい
のです。情報、よろしくお願いします。

私もmuttを使ってみたくて色々やってみました．
日本語ですが，よく覚えていないのですが，確か
/usr/include/limits.hのMB_LEN_MAXを1から2以上
(今は6にしています．理由はwebで調べたときそのような
例があったので．2で問題ないと思います)に変更してmakeするとうまくいったような．

またMaildir形式を使用する場合，mailを管理するときの
ファイル名に:が含まれるのがまずいみたいなので，#にして
います．(mh.cを修正した)

私も本格的には使用していないので，問題あるかもしれませんが，参考になれば幸いです．

なかなかレスもつかず、あきらめかけていたところでした。
ありがとうございます。

> /usr/include/limits.hのMB_LEN_MAXを1から2以上
> (今は6にしています．理由はwebで調べたときそのような
> 例があったので．2で問題ないと思います)に変更してmake
>するとうまくいったような．

2では、結果変わらず、6で日本語表示に成功しました。難航
していたので、感激しました。

「よーしバリバリいくぞ！！」と意気込んでいたら、今度は、
POPでサーバーからfetchする時に、暴走して、同じメッセー
ジが~/Mail/inbox/new（私の設定の場合）に無尽蔵に生成さ
れる不具合が発生しました。こんな現象は発生しませんでした
でしょうか？

　素人としては、根拠もなく、ファイルロックあたりが臭い
と思っているのですが．．．ちなみに、私の環境のコンパイ
ルオプションは以下の通りです。
ご教授いただけたら、幸いです。

System: CYGWIN_95-4.0 1.3.10s(0.51/3/2) (i586) [using slang 10402]
コンパイル時オプション:
-DOMAIN
-DEBUG
-HOMESPOOL -USE_SETGID -USE_DOTLOCK -DL_STANDALONE
+USE_FCNTL -USE_FLOCK
+USE_POP -USE_IMAP -USE_GSS -USE_SSL -USE_SASL
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR -HAVE_START_COLOR -HAVE_TYPEAHEAD -HAVE_BKGDSET
-HAVE_CURS_SET -HAVE_META -HAVE_RESIZETERM
+HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK -HAVE_WC_FUNCS -HAVE_LANGINFO_CODESET -HAVE_
LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS -HAVE_GETSID -HAVE_GETADDRINFO
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/d/Home/Mail"
PKGDATADIR="/usr/local/share/mutt"
SYSCONFDIR="/usr/local/etc"
EXECSHELL="/bin/sh"
-MIXMASTER

> POPでサーバーからfetchする時に、暴走して、同じメッセー
> ジが~/Mail/inbox/new（私の設定の場合）に無尽蔵に生成さ
> れる不具合が発生しました。こんな現象は発生しませんでした
> でしょうか？
イメージがよく掴めないのですが，fetchするたびに同じメッセーが取得されるのであれば，サーバからメッセージを削除しない設定かつ未読or既読にかかわらず取得するような設定になっているのでは?
詳しくはman muttrcのpop_delete, pop_lastで調べてみて下さい．
そうではなく，一回のfetchで同じメッセージが複数取得されるのであれば，ちょっとわかりません．当方ではそのような現象は一度も起こりませんでした．

因みに当方の動作環境は，
windows 2000 sp2
slang-1.4.5
mutt-1.3.27
libiconv-1.7
その他のcygwinのパッケージは最新の状態です．

> そうではなく，一回のfetchで同じメッセージが複数取得
> される

まさしく、一回のfetchで同じメッセージ（のコピー）が、
複数生成されます。

popでのメッセージ取得だけでなく、別のケースで似たよう
な現象も出ました。メッセージのディレクトリ間の移動なの
ですが、

フォルダーの設定が、
set mh_path=~/Mail
set mbox_type=MH
set spoolfile="~/Mail/inbox"
set folder="~/Mail"
set mbox="+mbox"
set tmpdir="~/tmp"
であるとします。

Muttを起動して、
spoolfile（~/Mail/inbox"）内のメールを読んだ後に"q"
で終了しようとすると、

「~/Mail/mboxに既読メッセージを移動するか？([no]/yes)」

のメッセージが出ます。ここで”ｙ”にすると、
「移動中．．．」（の様な）メッセージが表示されたまま、
戻ってきません。

慌てて、bashとMuttを強制終了させて、~/Mail/mboxのディ
レクトリの中を確認すると、ファイルの山がたっぷりと築か
れていました。

生成された個々のファイルの中身は全て同じで、/Mail/inbox
の中の移動されるべきメッセージの中の最初（MHなのでファ
イル名"1"）のファイルです。

~/Mail/inboxの中のファイルも全て残ったままです。

つまり、popが悪いのでなく、メッセージの移動系機能が、う
まく機能していないようです。

こうなると、gdbでもかけて、見るしかないのでしょうか。
と言っても、Cの知識は皆無だし．．．

私の環境でも同様の現象が発生するか試してみました．

私のmutt設定ファイルはMutt Japanese Editionでのサンプルとほとんど同じなのですが，Mailのフォルダの設定の部分のみをgokkoさんと同じにして，操作してみましたが現象は起きませんでした．

ただ，inboxからmboxにメッセージを移動させてもinboxには",1"といったカンマが付加されたファイルが残っていました．MH形式がどんなものなのか知らないので，これでよいのかどうかわかりません．

他のフォルダ形式でやってみてはどうですか?
(本質的な解決にはなってないか･･･)

因みにmuttのバージョンは何ですか?
私は
Mutt 1.3.27i-ja.2 (2002-01-22)
です．
slang等も最新バージョンを使用しています．
これらが同じで現象が起こるとなると，あとはOS
の違いくらいですかね．

早々のレス、いつも本当にありがとうございます。

> ただ，inboxからmboxにメッセージを移動させてもinbox
>には",1"といったカンマが付加されたファイルが残ってい
>ました．

　これは、MH形式の仕様と言うより、muttの仕様ぽいですね。
でも、"," + "元のファイル名"というファイルが内部的に生
成できずに、無限ループにでも入っているのかもしれません。
（また、勝手な憶測です）

> 他のフォルダ形式でやってみてはどうですか?
> (本質的な解決にはなってないか･･･)

Maildir形式でこれから試してみます。

> 因みにmuttのバージョンは何ですか?
> 私は
> Mutt 1.3.27i-ja.2(2002-01-22)
> です．
> slang等も最新バージョンを使用しています．

muttは、同じく
Mutt 1.3.27i-ja.2
です。
slangが、
slang1.4.2jp（ちょっと古い）
で、staticでビルドしたものですので、これも、
slang1.4.5jp
にて試してみます。
ところで楊志さんは、slangは、
static or shared
どちらでのビルドですか？

> これらが同じで現象が起こるとなると，あとはOS
> の違いくらいですかね．

こちらは、win95です（今時．．．）ので、厄介です．．．

> これは、MH形式の仕様と言うより、muttの仕様ぽいですね。

そうみたいですね．mh_purge変数によりファイルの削除を制御
できるみたいです．

> ところで楊志さんは、slangは、
> static or shared
> どちらでのビルドですか？

私はstaticです．(sharedの生成方法は知りません)

> こちらは、win95です（今時．．．）ので、厄介です．．．

このへんが関係あるんですかね．(win 9x上でcygwinを使った
ことがないので，なんとも言えませんが)

因みに，私とgokkoさんのcompile optionの違いは，

+DEBUG ･･･ デバッグするために指定した
+USE_DOTLOCK ･･･ 特になにも指定していない
-ENABLE-NLS ･･･ NLSは使用しないので指定した

です．1番目と3番目はconfigureのオプションで指定しました．
2番目は特に指定はしていません．

gokkoです。
結局、メールボックスの形式をMaildirにしても、その他
ライブラリを最新のものにしても、現象は変わりませんで
した．．．うーむ。

> 私はstaticです．(sharedの生成方法は知りません)

slangの場合、共有ライブラリはELF形式とやらで、
"make elf"でmakeできたはずです。dllではないので、
cygwinで機能するかはよくわかりませんです。
今回は私もslang-1.4.5jpのstaticでいきました。

> 因みに，私とgokkoさんのcompile optionの違いは，
> +DEBUG ･･･ デバッグするために指定した
> +USE_DOTLOCK ･･･ 特になにも指定していない
> -ENABLE-NLS ･･･ NLSは使用しないので指定した
> 2番目は特に指定はしていません．

私の、
-USE_DOTLOCK
も、configure時のオプションでは特になにも指定しない
に、逆にDOTLOCKが無効になったものです。

この辺りがOSの差でしょうか？

　今度は、ファイルロック周りのコンパイルオプションを
こねくり回してみます。

自己レスです。

> 　今度は、ファイルロック周りのコンパイルオプションを
> こねくり回してみます。

結局、ファイルロックを全て外したり色々試しても、状況に
進展はありませんでした。

私の実力では、これ以上進展は望めそうにありません。
楊志さんには、大変感謝しています。ありがとうございまし
た。非常に残念ですが、あきらめるしか、なさそうです。

勉強して出直します。有効な情報が有りましたら、ぜひ、ま
た宜しくお願いいたします。

あっ、
http://www.geocities.com/win32mutt/
にある、win32 native portの、mutt-1.3.26のバイナリを
試して見ましたが（日本語対応未？）、これだと、ファイル
生成の不具合自体は生じません。
と言うことは、解決策は有る、と言うことなのですけど．．．

> 私の実力では、これ以上進展は望めそうにありません。
> 楊志さんには、大変感謝しています。ありがとうございまし
> た。非常に残念ですが、あきらめるしか、なさそうです。

そうですか，残念です．現象がこちらで確認できれば，なんとか
なると思うのですが．

> http://www.geocities.com/win32mutt/

こんなのがあったんですね．情報ありがとうございます．
色々役に立ちそうな情報があるみたいなので，これから読んで
みます．なにか分かったらこちらに書き込もうと思います．

win98でmutt 1.3xを実行してみました．そうしたら，同じような
現象が発生しました．

調べてみたところ，lib.cファイルのsafe_rename関数が正しく
機能していないようです．

参考にhttp://www.geocities.com/win32mutt/patches.htmlの
Mutt-1.3.24iのソースをダウンロードして見てみると，やっぱり
パッチがあたっていました．
同様の修正をして，実行してみるとファイルが無数に作成される
現象は起きなくなりました．

ただし，ちょっとしか使ってないのでなんとも言えませんが，
メールをfetchしてもすぐに画面に表示されず，一度終了して
再び起動しないと表示されない現象がありました．(win 2000
ではそんな現象は起こりません)
ので，まだ問題がありそうな感じです．

muttオリジナル + 日本語パッチ + 上記のwin32muttパッチ
ぐらいすれば実用レベルになるのかもしれません．

もっと早く原因が分かればよかったのですが．

　感謝、感謝、感謝です。おかげさまで、私の環境でも、muttが使える様になりました！

> 調べてみたところ，lib.cファイルのsafe_rename関数が正しく
> 機能していないようです．
>
> 参考にhttp://www.geocities.com/win32mutt/patches.htmlの
> Mutt-1.3.24iのソースをダウンロードして見てみると，やっぱり
> パッチがあたっていました．
> 同様の修正をして，実行してみるとファイルが無数に作成される
> 現象は起きなくなりました．

　私も、そのソースは眺めていたのですが、lib.cだとは、全然わかりませんでした。
　早速、見よう見真似で修正して、ビルドし直しました。私のところでも不具合が解消した事を、改めて報告いたします。

> ただし，ちょっとしか使ってないのでなんとも言えませんが，
> メールをfetchしてもすぐに画面に表示されず，一度終了して
> 再び起動しないと表示されない現象がありました．(win 2000
> ではそんな現象は起こりません)

　MH形式で使っているのですが、こちらでは、”G”でfetchするとすぐに表示されます。メールボックスの違いでしょうか．．．

> muttオリジナル + 日本語パッチ + 上記のwin32muttパッチ
> ぐらいすれば実用レベルになるのかもしれません．
> もっと早く原因が分かればよかったのですが．

　本当にありがとうございます。これからガンガン使い込みます。

追伸：S-Langより、ncursesでビルドした方が、日本語表示の崩れが少ないような．．．