Internet関連業績(笑)
MH-plus のぺーじ
MH のどうでもいいような趣味の講座
はやし はるひさ
このページの最終更新日: 1999年 2月28日 日ようび 晴れ
/* ****************************** *
* このパッチによる変更点・仕様 *
* ****************************** */
このパッチを当てる事によって、MH オリジナルに対する数々のバグフィックス
が行われる他、options として、JAPAN, MIME_HEADERS, MH_PLUS, READLINE が
追加されます。また、options NNTP が options BPOP から独立します。以下、
それぞれについて、解説します。
なお、これらの options を全て指定しなかったとしても MH-6.8.4 オリジナル
にはなりません。バグフィックス等が行われているからです。どんなバグフィッ
クスが行われたかは CHANGES.JP を御覧下さい。
以下、「◆」記号部分は JP2c バージョンから大きく変わった部分を表します。
【1】 options JAPAN を指定すると…
様々なコマンドが日本語対応になります。
[1.1] 漢字コード
届いたメールを inc する際には、コード変換等は行ないません。つまり、メール
スプールに収められている、あるいは POP サーバー等が返すのと同じコードで
フォルダー内にセーブされます。そして、それらのメールを処理(出力・検索等)
する時に漢字コードの変換を行ないます。
使える漢字コードは、7bit JIS コード(以下 "JIS7" と略)、日本語 EUC (以下
"JEUC" と略)、Shift JIS コード(以下 "SJIS" と略)の三つですが、いわゆる半角
仮名文字(JIS X 0201 right half)や補助漢字(JIS X 0212)、また Mule-ML などで
使われている多言語メール等は取り扱えません。
漢字コードの指定は、入出力先に応じて独立に指定することができます。具体的
には ファイル入出力、画面出力、プロセス出力毎に設定することが出来ます。
その設定方法を以下に示します。
それぞれの漢字コードは、
ファイル入出力: 環境変数 MH_FILE_CODING
.mh_profileコンポーネント file-coding
画面出力: 環境変数 MH_DISPLAY_CODING
.mh_profileコンポーネント display-coding
プロセス出力: 環境変数 MH_PROCESS_CODING
.mh_profileコンポーネント process-coding
に与えられる値によって決定されます。いずれも上に書かれているものの値が優
先されます。
ここに指定できる値とその意味は以下の通りです。
漢字コード コンポーネント、環境変数の値
---------- ----------------------------
JIS7 ja_JP.jis7
JEUC ja_JP.euc
SJIS ja_JP.sjis
非使用 C
(注: これらは一見 locale の値を使っていますが、OS の locale は
全く使用していません。)
例えば画面出力の漢字コードとして JEUC を用いる場合は .mh_profile 中で
Display-Coding: ja_JP.EUC
などと指定して下さい。(大文字小文字は区別しません)
認識できない漢字コードを指定した場合や、デフォルトでは JIS7 となります。
◆また、値として、C を指定すると、日本語処理を行ないませんので、オリジナル
とほぼ同じ処理になります。この場合、環境変数 MM_CHARSET に使用する charset
(ISO-8859-X のどれか)を指定しておくと、その文字コードに対応します。なお、
C を指定する時は、三つの文字コードを全てを C にする必要があります。
ファイル入出力用の漢字コードが JEUC の場合は、ファイルを読み込むときに
限り JEUC に加えて JIS7 も正しく認識します。ファイル入出力用の漢字コードが
SJIS の場合は、ファイルを読み込むときに限り SJIS に加えて JIS7 も正しく
認識します。
◆なお、JP2c バージョンでは環境変数 LANG や環境変数 LC_CTYPE なども見るよう
になってましたが、一般に OS の日本語 locale とメールスプールの漢字コードは
違っている事が多いので、色々と問題が起こる事が分かりました。また locale を
使ってないのに LANG を見るというのもあまりいい実装でもないでしょう。そこで、
JP-3.x では、これらの環境変数は見ないようになっています。スプールのコードが
JIS7 でない場合は、.mh_profile コンポーネントなどで対処するようにして下さい。
◆なお、現在の所、vmh の表示コードは上記設定に依らず、JEUC になります。
また、メールを出す時(post(send))には、漢字コードの設定によらず、メッセージ
のボディ部は draft ファイルの漢字コードのまま sendmail, smtp, popd などに
送られます(ヘッダ部に関しては [2.5] を参照)。
[1.2] コマンド等の日本語化
mh-format が日本語化されますので、format ファイル中に日本語を書く事も
できます。inc, scan, repl 等でも文字化けを起こさないようになります。
また、mhl が日本語化されますので、mhl の format ファイル中に日本語を書け
る他、折り返し改行等で化けたりしなくなります。
◆また、pick で検索文字列に日本語が使えるようになります。正規表現でも、
日本語文字、ASCII 文字を問わず、それぞれを一文字と認識します。
フォルダー内に保存されているメールの文字コードが JIS7 であっても、検索
文字列に JEUC (file-coding コンポーネントに SJIS を指定してる時は SJIS)を
指定して検索…等ができますので、フォルダー内のコードと OS の日本語 locale
が違う場合にも簡単に検索できる事でしょう。:-) もちろん、検索文字列は同じ
コードを指定することも出来ます。
◆さらに、mh-alias で日本語が使えるようになります。例えば、AliasFile 内に
otomo: 犬,猿,\
雉
という風に書けます。ただし、mh-alias に日本語が含まれている場合は options
MIME_HEADERS を指定し、ヘッダが自動的に RFC-2047 エンコードされるような
設定等も必要になってくるかと思います。詳しくは [2.5] を参照して下さい。
[1.3] MIME 形式における charset="ISO-2022-JP" のサポート
mhn を用いて MIME 形式のメッセージを作成する際(*)、draft ファイルが JIS7
コードで書かれている場合は charset="iso-2022-jp" が、それ以外の 7bit コード
で書かれている場合は charset="us-ascii" がつきます。
判別はファイル中に最上位ビットの立ったコードを含まず、ESC $ @ か ESC $ B
を含んでいれば JIS7 としています。
(*) comp あるいは repl の際に、"What now?" の状態で "send" とする前に、
"edit mhn" と入力する。あるいはこれを自動的に行うには、.mh_profile
の中に "automhnproc: mhn" を入れておく。詳しくは man mhn や FAQ.JP
を参照して下さい。
◆なお、JP2c バージョンでは、options JAPAN が指定されている時には常に
charset="iso-2022-jp" が付くようになってましたが、US-ASCII メールを書いた
時にも iso-2022-jp が付くのはあまり良くはないと思われるので、判別する
ようになっています。
[1.4] タイムゾーン
timezone "JST" を正しく認識します。mh-format の関数 tzone や pretty の
結果が、"+0900" の場合に "JST" を使うようになります。
更にコンフィグレーション時に "options ATZ" を指定した場合は、送られる
メッセージの "Date" フィールドのタイムゾーンも "JST" になりますが、これ
をすると RFC-1123 の規定を満たさないことになりますので、ATZ は指定しない
事をお勧めします。:-)
また、backward compatibility のために "options ATZ" が指定されていない
場合でも、"JST" を "+0900" の意味であると認識するようにしました。
【2】 options MIME_HEADERS を指定すると…
RFC-2047 で規定されている非 US-ASCII ヘッダーに対応します。
◆JP2c バージョンでは、options JAPAN を選択すると、自動的にこの機能も
選択されていましたが、JP-3.x では二つのオプションを分けてます。
[2.1] 非 US-ASCII ヘッダー
RFC-2047 で規定されている非 US-ASCII ヘッダー(日本語ヘッダーなど)の一部
を使用することができます。サポートされる形式は、options JAPAN が同時に指定
されていて、使用する漢字コードの設定を C にしていない場合は
charset="ISO-2022-JP" の "B"-encoding 及び "Q"-encoding です。(encode 時
には "B"-encoding のみ)
◆なお、options JAPAN が指定されてない時や、使用する漢字コードの設定を C に
している場合は charset="ISO-8859-X" のうちのどれか一つ (環境変数 MM_CHARSET
で指定されたもの)が使えます。(encode 時には "Q"-encoding のみ)
現時点の MH では多言語には対応してないので、これらを同時に含むものは処理
出来ません。
◆なお、JP2c バージョンでは、RFC-1342 で規定されている encode/decode を行っ
てましたが、現在、この規格は破棄されていて、新たに RFC-2047 が挙げられてい
ます。そこで、JP-3.x では RFC-2047 に沿って encode/decode をするように変更
しました。両者の違いは大まかに次のような感じです。
(a) RFC-2047 では structured header (From: など構造を持つヘッダー)では、
quoted-string (「"」で囲まれた文字列)の中には encoded-word
(「=?ISO-2022-JP?B?....?=」とかの部分)が現れてはならないという規定になっ
ています。
このため、「"」で囲まれた中に日本語文字を含むような場合、日本語文字列
部分だけをエンコードしては規定を満たさなくなるので、一文字でも非 US-ASCII
文字を含む場合は「"」内全体をエンコードします。
(b) RFC-2047 では、encoded-word の前後には必ずスペースが必要という規定
になっています (コメントを表す「(」の直後や「)」の直前を除く)。
このため、日本語文字とASCII文字が間にスペース無しで繋がってるよう
な文字列をエンコードする場合、日本語文字だけをエンコードしていては、
スペーシングが保存できません。このため、語(ここではスペースで区切られた
一つの文字列)の中に一文字でも非 US-ASCII 文字を含む場合は、その語全体を
エンコードします。
(c) RFC-2047 では、任意の長さのスペースが二つの encoded-word で囲まれて
いる場合、デコードする際には、その囲まれたスペース全てを取り除くという
規定になってます。
このため、二つの日本語文字列の間にスペースがあるような文字列で、それ
ぞれの日本語文字列だけをエンコードしていてはスペーシングが保存できません。
このため、エンコードすべき文字列同士の間にスペースがある場合、そのスペース
ごとエンコードします。
なお、(a), (b) に関して、RFC-2047 では「=?ISO-2022-JP?B?..?=」という
形式の文字列が「"」の中にあったり、直前にスペースが置いてない場合は、それ
は encoded-word とは解釈しない事になっていて、そういう場合はデコードすべき
でありません。それはそのままの ASCII テキストと解釈すべきです。
とはいうものの、世の中にはそういう形式のヘッダーを送り出すメーラーが
非常に多いというのもまた事実です (JP2c もそうでした)。そういうメールを
どう表示すべきかは議論の分かれる所でしょう。JP-3.x では一応、暫定的に(?)
この形式でもデコードするようにしています。でも、厳密に言えば、これは
間違った実装です。:-<
[2.2] mh-format による encode/decode
RFC-2047 形式の非 US-ASCII ヘッダーの解読のために、以下の二つの mh-format
関数が追加されています。
関数 引数 戻り値 説明
hencode expr string 日本語等の文字列を RFC-2047 形式に変換
hdecode expr string RFC-2047 形式を日本語等の文字列に変換
これらの関数はいずれもトップレベルにある時は暗黙的に putstr として取り
扱われます。
hdecode 関数で RFC-2047 形式にエンコードされた文字列を通常の日本語文字列
に戻す事が出来ます。例えば、scan format 中で、「%15(hdecode(friendly{from})」
とか、「%(hdecode{subject})」などとして呼び出します。
◆なお、JP-3.x では、-form オプションを指定せずに scan を実行した場合は、
デフォルトで hdecode 関数が呼び出されるようになっています。このため、何の
設定もしてない状態の場合は、scan しただけで、ヘッダーの RFC-2047 文字列は
デコードされます。
一方、-form オプションで、format ファイルを指定した場合は、その指定に
従い、そのファイル中で hdecode 関数が使われていればデコードしますし、使わ
れてなければデコードしません (従来と変わらず)。
[2.3] mhl の format ファイル内の decode オプション
◆mhl の format ファイル内のオプションとして decode が追加されます。
このオプションが指定されているコンポーネントは、出力の際にそのコンポー
ネント内の RFC-2047 文字列をデコードします。例えば、「Subject:decode」
などと指定できます。
なお、mhl の format ファイル内では formatfield 指定を用いて mh-format
を呼び出すことができますので、「Subject:formatfield="%(hdecode{text})"」
などと指定しても RFC-2047 文字列はデコードできますが、この両者は行の折り
返しやスペーシングが異なります。一般には decode オプションを使う方が
奇麗に整形されるはずです。
◆なお、options MIME_HEADERS を指定すると、mhl.format と mhl.headers は
decode オプション入りの format ファイルがインストールされます。このため、
何の設定もしてない状態なら mhl で RFC-2047 文字列はデコードされる事になり
ます。mhl で RFC-2047 文字列をデコードされたくない場合は、decode オプション
を含まない format ファイルを用意して、それを -form オプションで指定する
ようにして下さい。
[2.4] mhn -list 時の decode
◆「mhn -list」した際に、各パートの Content-Description: ヘッダーの内容の
一覧が表示されますが、ここに書かれている RFC-2047 文字列はデコードして表示
します。
なお、「mhn -list」では mh-format が使えませんので、デコードしないように
設定する事は出来ません。options MIME_HEADERS が指定されていると必ずデコー
ドします。そもそも「mhn -list」はメールの MIME タイプや multipart の一覧
を表示するという、MIME のためのコマンドなので、このコマンドに関しては、
デコードして欲しくないという要望もまず無いのでは…と想像しますが、ここでも
mh-format が使えると便利かも知れませんね。TODO.JP 参照。
[2.5] mhn エディット時の自動変換
◆mhn を用いて MIME 形式のメッセージを作成すると、draft に MIME-Version:
や Content-Type: といったヘッダーが付けられますが、この時、同時にヘッダー
の非 US-ASCII 文字(日本語文字等)は RFC-2047 形式にエンコードされます。
[2.6] メッセージ送信時の自動変換
post (および spost)に以下のオプションが追加されます。
-hencode
-nohencode
オプションとして -hencode が指定された場合は、メッセージのヘッダー部に含ま
れる非 US-ASCII 文字(日本語文字等)が自動的に RFC-2047 形式 (日本語文字の
場合は charset="ISO-2022-JP", "B"-encoding)に変換されて送信されます。
-nohencode が指定された場合は、ヘッダー部の非 US-ASCII 文字は変換されずに
そのまま送信されます。いずれの場合もメッセージのボディ部は影響を受けません。
◆デフォルトは、draft ファイルに MIME-Version: ヘッダーが含まれている場合は
-hencode と同じで、含まれてない場合は -nohencode と同じ働きをします。これ
は、RFC-2045 に依ると、メールは MIME-Version: ヘッダの存在の有無によって、
MIME メールかどうかを区別することになっていて、MIME メールではヘッダの非
US-ASCII 文字は必ず RFC-2047 encode をしなければならない事になっている事を
受けたものです。
つまり、逆に言うと、ヘッダーの非 US-ASCII 文字を RFC-2047 encode したく
ない場合は、draft に MIME-Version: ヘッダーを付けてはなりません。
なお、-hencode が指定された場合や、デフォルトの状態で MIME-Version:
ヘッダーを含む場合は、.mh_profile の signature: コンポーネント(UCI option
を指定してコンフィグレーションされた MH の際は更に ~/.signature ファイルの
中身も)に書かれたユーザー署名に含まれている日本語文字等の部分も、自動的に
RFC-2047 形式に変換されます。
◆さらにこの場合、mh-alias に日本語等が書かれている時には、アドレス部の
alias を展開して日本語等が出てきた時に、それも自動的に RFC-2047 形式に
変換します。
[2.6] 非 US-ASCII ヘッダーの検索
◆pick でヘッダー等を検索する際に、検索文字列として非 US-ASCII 文字(日本語
文字等)の文字列を指定した場合は、フォルダー内のメールのヘッダーが RFC-2047
エンコードされていても、それをデコードしたものにマッチすれば、検索にヒット
するようになります。
つまり、エンコードされた文字列をデコードされた文字列で検索できるという
事です。例えば、
Subject: =?ISO-2022-JP?B?GyRCRnxLXDhsSEcbKEI=?=
こういうヘッダー(ちなみに「日本語版」と書かれています)を
% pick -search '本語'
で見つけ出すことが出来ます。
なお、現バージョンでは pick は MIME の body part header には対応してま
せんので、multipart の各パートの Content-Description: ヘッダーに書かれて
いるエンコード文字列等を、デコードした文字列で検索する事はできません。
【3】 options MH_PLUS を指定すると…
様々な拡張機能が使えるようになります。
[3.1] pgped/pgpshow を multipart/signed、multipart/encrypted に対応
◆mh-6.8.4 で追加された PGP 対応コマンド pgped/pgpshow を multipart の PGP
に対応させました。mh-6.8.4 では pgped/pgpshow はスクリプトで実現されていま
すが、options MH_PLUS を指定すると、代わりに C で書かれたバージョンをイン
ストールするようになります。C バージョンはスクリプトバージョンの上位互換
(のはず ^^;;)です。
options MIME が指定されている場合、multipart/signed や multipart/encrypted
といった Content-Type のメールを show すると、自動的に pgpshow が呼ばれ、
pgpshow は PGP を呼んで電子署名の照合や暗号メールの復号を行い、その後、
pgpshow は照合後・復号後のメールを show する形になります。
PGP がインストールされてない場合は、pgpshow は multipart/signed の場合は
照合なしに show します。multipart/encrypted は PGP がないと復号できないの
で、どうしょうもありません。:-)
次に、comp あるいは repl の際に、"What now?" の状態で "send" とする前に、
"edit pgped" などと入力すると、draft ファイルが PGP で処理されます。使える
オプションは pgped -help でも見られますが、
edit pgped [-[no]mime] [-[no]sign] [-[no]encrypt]
です。-mime を指定すると、multipart/signed や multipart/encrypted になり、
-nomime だと生の PGP メール (mh-6.8.4 形式) となります。デフォルトは -mime
です。
また、mh-6.8.4 オリジナルのスクリプト版との互換性を合わせるために (あまり
意味はないでしょうけど… ^^;;)、デフォルトでは署名・暗号化は共にするように
なっていますが、-sign オプションだけを指定した場合は、署名だけして暗号化は
しないようになります。
.mh_profile に「pgped: -mime -sign -noencrypt」などと書いておくと、これ
がデフォルトのオプションになります。
[注] -nomime で作成される mh-6.8.4 形式の PGP メール(application/pgp 等)
の規格は、Internet draft として公開されてましたが、結局 RFC に成る事なく、
破棄されてしまったようです(^^;;)。実際、使用してるソフトも mh-6.8.4 以外
にはあまり無いようですし、-mime での使用が推奨されるかと思われます。:-)
-mime オプションを指定すると、ヘッダーに MIME-Version: 等がない場合は、
自動的に edit mhn されます。「edit pgped -mime -nosign -noencrypt」は
「edit mhn」と同じ効果があります。これを利用して、automhnproc: に pgped
を指定し、pgped: コンポーネントで -mime -sign -noencrypt など指定しておく
と、送り出す全てのメールを multipart/signed にする…とかも可能でしょう。:-)
[3.2] rmm で Trash-Folder: (ゴミ箱フォルダー)の設定が出来るように
◆.mh_profile に「Trash-Folder: +trash」などと書いておくと、メールを rmm
で消すと、そのメールは +trash フォルダーに移動になり、+trash フォルダー
で rmm するとそのメールは完全に消えるようになります。+trash フォルダー
は rmm 以外のコマンドに取っては全く通常のフォルダーとして機能しますので、
削除済みメールは scan 出来るし、復活する際は別のフォルダーに refile すれ
ばいいです。これは、MH-e から削除する場合でも有効です。
なお、Trash-Folder: コンポーネントが指定されてない場合は、従来通り、"#"
や "," などのついた名前に rename される事になります。また、rmmproc: が
指定されてる場合は、rmmproc: が優先されますので、Trash-Folder: の指定は
無視されます。
また、MH にはフォルダー名が "+" で始まってる場合は ~/Mail/ からのパスで、
"@" で始まってる場合は、カレントフォルダーからの相対パスになるという仕様が
ありますので、「Trash-Folder: @trash」と指定する事で、各フォルダー毎に
ゴミ箱を設ける事が出来ます。これで、+inbox のメールを消すと +inbox/trash
に移動になり、+project のメールを消すと +project/trash に移動する事になり
ます。
そして、この設定の場合、+foo/bar/trash など、フォルダー名の最後の部分
が Trash-Folder: に一致した場合は rmm すると、ファイルを実際に消します。
+foo/trash/bar とか、最後の部分でない場合は通常フォルダーと見なして、
+foo/trash/bar/trash に移動します。これは「Trash-Folder: @trash」の場合
の話であって、「Trash-Folder: +trash」の場合は、+trash 一つだけがゴミ箱
と見なされます。
[3.3] message/rfc822 を mhn -list すると、Subject: も見るように
◆「mhn -list」した際に表示される一覧には Content-Description: ヘッダーの
内容がありますが、Content-Type: が message/rfc822 であり、且つ、
Content-Description: ヘッダーが存在しない場合は、代わりに Subject: を表示
するようにしました。
これで、例えば、multipart/digest 形式のメールを mhn -list すると、各パート
の Subject: 一覧が表示されるようになります。
[3.4] mhn に -junet オプションと、-8bit オプションを追加
mhn を用いて MIME 形式のメッセージを作成すると、draft ファイルが JIS7
で書かれている場合は charset="iso-2022-jp" が、それ以外の 7bit で書かれて
いる場合は charset="us-ascii" がつきますが (options JAPAN 時)、8bit で書か
れている場合は、quoted-printable に変換されて、charset="unknown-8bit" が
付きます。([1.3] も参照)
この時、環境変数 MM_CHARSET が指定されている場合は、"unknown-8bit" の
代わりに MM_CHARSET の内容がつく事になります。
しかし、普段使ってるエディターが例えば、JEUC にしか対応してないという場合、
JEUC でメールを書き、それを JIS7 に変換して送り出すようにしているかと思わ
れますが、mhn で MIME 形式にする際にはまだ draft ファイルは JEUC のままで
あり、この状態で文字コードを判別すると "unknown-8bit" になってしまいます。
MM_CHARSET をきちんと設定したとしても charset="EUC-JP" の quoted-printable
にしかなりません。
◆そこで、「edit mhn」の際に、-junet オプションをつけると、まず draft ファ
イルを JIS7 に変換し、その後、文字コードを判別して charset を付けるように
なります。つまり、JEUC の draft が、JIS7 で charset="iso-2022-jp" 付き MIME
メールになる訳です。なお、draft ファイルは file-coding コンポーネントで指定
された漢字コードで書かれていると想定されますので、SJIS を指定してある場合は、
SJIS の draft ファイルを JIS7 に変換する事になります。
また、「edit mhn」の際に、-8bit オプションをつけると、8bit メールでも
quoted-printable には変換せずに、「Content-Transfer-Encoding: 8bit」を
付け、生のまま MIME 形式にするようになります。
◆また、8bit メールを -8bit オプションで処理する際には charset には環境変数
MM_CHARSET の値が使われますが、この値が iso-2022-jp であるときは、8bit で
あるのにかかわらず「Content-Transfer-Encoding: 7bit」をつけます。これは、
post 後に sendmail 等で JEUC → JIS7 等の文字コード変換される場合を想定して
います。
デフォルトは -nojunet -no8bit です。これらのオプションは mhn エディット
の時以外は関係ないので、.mh_profile に「mhn: -junet」などと書いておく事も
出来ます。
[3.5] POP 接続のデフォルトのプロトコルを設定できるように
◆POP 接続をする際に inc や msgchk に -[no]apop, -[no]rpop 等のオプション
を指定する事で、接続プロトコルを指定できますが、これらのオプションを指定し
ない場合のデフォルトを mtstailor の rpop コンポーネントで指定できるように
なります。値として 1 を指定すると RPOP、-1 を指定すると APOP、そして 0 を
指定すると通常の POP がデフォルトとなります。
つまり、-[no]apop, -[no]rpop 等を指定しない時は通常の POP になるように
するには、/usr/local/lib/mh/mtstailor (ディレクトリはサイト依存)に、
rpop: 0
と書くといいです。もちろん、これは pophost が指定されてない時には意味しま
せん。
【4】 options READLINE を指定すると…
◆msh でコマンドライン編集やヒストリー機能、フォルダー名補完が使えるように
なります。
C-f, C-b でコマンドラインを行き来したり、C-p, C-n でヒストリを遡ったり
出来ます。GNU の libreadline をリンクするようになるだけなので、詳しくは
readline のマニュアルを御覧下さい。~/.inputrc でカスタマイズも出来るはず
です。なお、この機能は libreadline.a がインストールされてないと使えません。
libreadline もあまりに古いバージョンだと使えないと思います。:-)
補完はコマンドラインの先頭ではコマンド名の補完を行いますが、引数部分で
"+" や "@" で始まる語はフォルダー名と見なして、補完します。
【5】 options NNTP を指定すると…
NNTP を喋るサーバーに接続して NetNews を読む事が出来るようになります。
従来、options NNTP は「bboards: nntp」という形で、options BPOP が同時に
指定されている事が前提になっていました。また、POP が絡んでいるので、NNTP
では必要ないのにパスワードを聞いてきたり、crypt 関係のライブラリをいじっ
てたり…という状態でした。
◆JP-3.x では、options NNTP は BPOP 無しでも指定できるようになっています。
パスワードや crypt 関係からも独立させました。
options NNTP を指定すると、bbc というコマンドがインストールされます。
% bbc -host news.server.name fj.mail
これで、news.server.name というマシンに NNTP 接続し、fj.mail というニュース
グループを読むモードに入ります。news.server.name 部分には自分のサイトの
ニュースサーバー名を指定します。
なお、/usr/local/lib/mh/mtstailor (「/usr/local/lib/mh」部分はインス
トール時に変更可能) に「nntphost: news.server.name」と書いておけば、
「-host news.server.name」オプションは省略できます。
この bbc のモードで、普通に scan や show する事で、NetNews を読む事が
出来ます。なお、この時、見えてる記事はローカルファイルとしては存在せず、
仮想的に一つのニュースグループを一つのフォルダーに見立てているだけです。
しかし、例えば「refile +news/fj.mail」などとすると、カレントメッセージを
ローカルの +news/fj.mail フォルダーに保存します。bbc のモードを終らせる
時には exit とします。
bbc の起動直後は、未読記事は unseen シーケンスに設定されてますので、
そのニュースグループの記事は全て保存する…という場合は、bbc 起動後、常に
「refile unseen +news/fj.mail」とだけして終了するようにすればいい事に
なります。
なお、bbc は標準入力がパイプの場合は、そのパイプからコマンドを読みとっ
て終了するようになります。上記の場合は
% echo "refile unseen +news/fj.mail" | bbc fj.mail
という技も使える事になります。後は MH なり、MH-e なりで読んで下さい。:-)
もっとも、この方法はこまめに記事を消さないとあっという間にディスクが溢れ
ると思いますが…。:-)
/* MH-plus project (mh-plus あっとまーく material.chem.eng.himeji-tech.ac.jp) */
Internet関連業績(笑)
MH-plus のぺーじ
MH のどうでもいいような趣味の講座
はやし はるひさ
このページの最終更新日: 1999年 2月28日 日ようび 晴れ