NetBSD/i386 9.4でThunderbirdを動かそうとしたが断念したものの、Geminiとの対話は役に立った

NetBSD/i386 9.4のMATEデスクトップ環境が復活したので、Thunderbirdを入れてみようと思い立ちました。随分前にはpkgsrcでThunderbirdをインストールした記憶がありますが、何時の頃からかpkgsrcからは消えてしまいました。

 

NetBSDネイティブでなくても、LibreOfficeのようにLinuxエミュレーション環境でなんとかならないか試してみました。Geminiに相談しながら、インストールを試みます。インストール事態は、入手したファイルを展開するだけなので、別に難しくはありません。しかし実行しようとするとエラーが出ます。ここでGeminiに相談すると、いろいろとアドバイスしてくれます。

 

Geminiとの対話を繰り返しながら、あれこれやってみましたが、最終的にThunderbirdを動かすことはできないという結論に至りました。それはそれで構わないのですが、Geminiとの対話は、とても有効だったと感じました。Geminiのアドバイスが常に正確で間違いないという訳ではないのですが、それは現実の「詳しい知人」であっても似たようなものです。「詳しい知人」に比べてれば、Geminiの方が詳しい（知識量が多い）と思います。しかも「詳しい知人」は、機嫌を損ねると、へそを曲げたりしますが、Geminiには、そのような心配はありません。

 

Gemini（というか生成AI）は、うまく使えば、とても便利だと思います。しかし、Geminiが常に正しい情報を伝えてくれるわけでもなく、その伝えてくる情報を吟味して、何をするのか自分自身が理解している必要があると思います。Geminiがあれば、自分は勉強しなくても良いわけではなく、むしろ更に勉強しなければならないでしょう。

 

Geminiにも出来ることと出来ないことがあると思いますが、うまく使いこなせれば、とてもメリットがあると思います。 

T98-NEXTのNFD形式はxnp2では扱えなかった

NetBSD/i386でxnp2が動くようになり、PC-9801用Wizardryが動作したので、Windows 11上のT98-NEXTで保存したファイルを使おうとしたら、認識されませんでした。T98-NEXTではNFD形式ですが、xnp2はFDI形式を期待しているようです。FDイメージファイルの形式は、なんでも良いかと思っていましたが、そうでもないようです。

 

ネットを検索すると、FDイメージファイルの形式を変換するプログラムが見つかりました。NFD形式からFDI形式に変換できましたが、xnp2では認識されません。

 

変換されたフィルを確認すると、認識されるFDI形式とはファイルサイズが違うようです。強引ですが、バイナリエディタを使い、余分なところを切り詰めてみました。そうしたら、xnp2でも認識されるようになりました。

 

これで、Windows11上のT98-NEXTで途中までプレイした結果ファイル（NFD形式）を、FDI形式に変換し、末尾を切り落として、NetBSD/i386にコピーすれば、xnp2で続きをプレイできます。途中の手順がやや面倒ですが、機械的に処理する方法を探ってみようと思います。

NetBSD/i386 9.4上のxnp2 0.86でPC-9801用Wizardryが動いた

NetBSD/i386 9.4にxnp2 0.86をインストールできたので、PC-9801用のWizardryを動かしてみました。何のトラブルに見舞われることもなく、あっさりと動作しました。

 

Windows11上でT98-NEXTを使っている場合には、FDイメージのファイルには拡張子「.NFD」がつくのですが、xnp2は「.FDI」か「.D88」を期待するようです。しかしこれは拡張子のネーミングの問題に過ぎないと思うので、FDイメージの構造が異なるわけではないでしょうから、おそらく問題にはならないと思います。

 

 xnp2は、FDイメージファイルをアクセスする際に、FDドライブのシーク音を出します。これはT98-NEXTには無かった機能です。物理的なFDドライブが存在するわけではないので、気分の問題ですが、シーク音を耳にすると懐かしさを覚えます。またリセット直後には、おなじみの「ピポッ」という音がなります。これはT98-NEXTもそうでした。これが聞こえるとPC-9801の思い出が蘇ります。

 

これで、Windows11上のT98-NEXTと、NetBSD/i386上のxnp2で、Wizardryが遊べるようになりました。両方の環境を使って遊ぶには、途中経過を記録したFDイメージの取り扱いが問題になってくるでしょう。何か良い方法を考えようと思います。 

NetBSD/i386 9.4でxnp2 0.86が動作した

NetBSD/i386 9.4環境で、パッケージからnxp2をインストールしようとしました。そうしたら共有ライブラリの不整合が発生し、pkgin full-upgradeを実行しました。するとエラーが出て、Geminiに相談しながら調査したら、パッケージ管理ディレクトリが/var/db/pkgと/usr/pkg/pkgdbの2箇所に見つかり、これが原因で深刻な不整合が起きていることが発覚しました。Geminiのアドバイスを受けながら、インストール済みの全パッケージを削除し、入れ直しました。しかし欠けているパッケージがあるので、確認しながら、追加インストールして、ようやくMATEデスクトップ環境が復活しました。

 

あらためて、本来の目的だったxnp2をインストールしました。何も問題がなくインストールできました。

 

動かしてみたのですが、PC-9801の起動時画面が出るはずですが、文字がかすれて読めません。フォントを別途入手する必要があるようです。Neko Project 21/Wのサイトから「font.bmp」を入手して「~/.np2/font.bmp」に置きました。これで起動時画面の文字が読めるようになり、一歩前進です。

 

次は、Wizardryが動くか確認しようと思います。 

NetBSDのパッケージ管理情報が/usr/pkg/pkgdbと/var/db/pkgで混乱していた

NetBSD/i386にxnp2を入れようとしたら、共有ライブラリのトラブルが発生したので、pkginを使ってfull-upgradeを試みました。そうしたら、MATEが消えてしまい、ログインできなくなりました。あらためてpkginでMATEをインストールしようとしたら、多くのエラーメッセージが出て、インストールできません。

 

以前であれば、問題解決のためにGoogleで検索して似たような事例を探していたのですが、最近はGeminiに相談するようになりました。MATEのパッケージがインストールできないので解決したいというのが、Geminiに相談したことなのですが、Geminiがアドバイスしてくれたコマンドを叩くとエラーが発生します。それをGeminiに伝えると、また別のアドバイスをくれるので、対話を繰り返していると、次第に深みにはまってきました。

 

トラブルの根本原因は、NetBSDのパッケージ管理情報が/usr/pkg/pkgdbと/var/db/pkgの2か所に存在していることが判明しました。このように2か所に存在しているので、双方の情報が重複したりしていて、不整合も発生しているようです。こうなってしまうと、MATEがどうこうという問題よりも、この不整合を如何に解決するかという方が、重大な問題になりました。

 

Geminiのアドバイスを貰いながら対処を試みましたが、深刻な障害が解消しません。多少強引ですが、最後の奥の手として、インストール済みのパッケージをリストしておき、インストール済み全パッケージを削除し、あらためてインストールしなおすことにしました。

 

今は、インストール済のパッケージを削除しているところです。1,000以上ものパッケージがインストールされていたので、削除するだけでも長時間かかります。削除が終わったら、再インストールしますが、それも長時間かかるでしょう。 

NetBSDにバイナリパッケージxnp2を入れたらMATEが動かない

NetBSDのパッケージにはPC98エミュレータxnp2が含まれていることがわかったので、バイナリパッケージを入れてみました。バイナリパッケージを入れるのに「pkgin」を利用しています。OSがNetBSD/i386 9.0なので、パッケージ2025Q4のNetBSD/i386の9.0用を参照しました。

 

xnp2に依存関係のあるパッケージが有るのか無いのか不明ですが、最近1年以上もパッケージを更新していなかったので、追加更新に60個弱のパッケージが必要になりました。各々のパッケージが本当に必要なのか厳密に確かめることができるかもしれませんが、それをするなら「pkgin」を使う意味がないと思い、それらのパッケージを全てインストールしました。

 

インストール自体には問題がありませんでしたが、ログインできなくなりました。正確には、XDMでログインしたあとで、MATEを動かしているのですが、共有ライブラリが見つからないとのことで、XDMログイン画面に戻ってしまいます。rootは、MATEではなく,TWMのままなので、問題ありませんでした。「~/.xsession-errors」を確認すると、共有ライブラリが見つからないとあります。確かにその通りでしたが、シンボリックリンクを張れば解決できそうなので、対処しました。そして再度ログインしてもXDMに戻ってしまいます。別の共有ライブラリが見つからないようです。これを繰り返したら、最終的に共有ライブラリに定義されていないものがあるというエラーになりました。

 

もうお手上げなので、Geminiに相談したら、libxkbcommonという共有ライブラリを再インストールすることを勧められました。やってみましたが、解決しませんでした。それをGeminiに訴えると「pkgin full-upgrade」を試してみるように言われました。これなら解決できそうですが、作業時間が長いですし、xnp2とは関係ないところで、別な不具合が出てくるかもしれません。

 

しかし、これ以外に対処方法はないと思うので、もう後戻りはできない状態になっています。何か別の問題がでたら、また解決方法を模索するしかないでしょう。 

NetBSDでPC98エミュレータ

Windows 10を使っていたころに、T98-NEXTというPC98エミュレータを使ってWizardryを遊んでいました。「PC-9800シリーズエミュレータの現況」という記事によると、PC98エミュレータは他にもあるようです。しかしMicrosoft Windowsなら選択肢は多いかもしれませんが、非Windowsでは選択肢が限られると思います。

 

ちょっと検索したら、次のような記事が見つかりました。これらの記事では、NP2kai（Neko Project II 0.86 kai）を使って、ソースからビルドしているようです。OSにはUbuntuを使っているようなのですが、私はNetBSD/i386を使いたいのです。

• 令和の時代にLinuxにPC-98x1エミュレータを入れる
• Ubuntu 22.04で98エミュレータを動かす

 

上述した記事を参考にすれば、NetBSD/i386環境であっても、ソースからビルドできるのではないかと思います。ビルド環境を整えたり、ビルドしてみてエラーが出るかもしれませんし、何かと手間がかかるだろうとは思います。もしかしたら何の苦労もなくビルドできてしまう可能性もありますが、そう簡単ではないだろうと予想しています。

 

自前でビルドする前に、ちょっとパッケージを確認したら、なんと「emulators/xnp2」がありました。これは「Xnp2 is a port for UNIX with X11 of "Neko Project II" PC-9801 emulator.」だそうです。自前でビルドしなくても、既にパッケージが用意されていました。

 

このパッケージをインストールしてみようと思います。このPC98エミュレータでWizardryを動かしてみようと考えていますが、問題なく無事に動いてくれるか心配です。もしトラブルようであれば、デバッグすることになるかもしれませんので、自前でビルドできる環境を整えておく必要が出てくるかもしれません。 

モバイルSuicaを使ってみる

スマホにモバイルSuicaの設定を済ませたので、実際に利用してみました。何かトラブルが発生するのではないかと戦々恐々だったのですが、何事もなく、あっさりと利用できました。あまりにも何も問題がないので、驚いています（問題がなくて、あたりまえだとは思いますが）。

 

強いて言えば、スマホケースにストラップを付け、胸に下げているのですが、そのため改札を通る際に、多少腰をかがむ必要があるくらいでしょうか。

この調子なら、Smart ICOCAのクイックチャージのサービスが終了しても、モバイルSuicaに移行出来そうです。

/var/spool/clientmqueue

FreeBSD/amd64を使用して自宅のメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSでメールを読んでいます。メールを送る時はmewを使うか、場合によってはMicrosoft Windows上のThunderbirdを使用しています。数日前、procmailを呼び出すのに、.forwardで指定するのを止めて、.fetchmailrcに変更したところでした。

 

procmailの呼び出し方法を変えただけなので、これまでと同様にメールが振り分けられるはずです。実際その通りなのですが、FreeBSD/amd64自身のrootが送信したメールが見当たらないことに気づきました。root宛のメールは、aliasesでローカルユーザに渡しています。

 

まず最初に確認するのはログファイルです。/var/log/maillogを除くと、エラーが記録されています。同じようなエラーが何度も出力されているようです。目視した限りでは、次のエラーでした。

1. alias database /etc/mail/aliases.db out of date
2. get_error=error:0A000126:SSL routines::unexpected eof while reading
3. info=Bare carriage return (CR) not allowed

 

1番目のエラーは、Webを検索すると「FreeBSD: サーバーOS更新 12.3 → 12.4」という情報が見つかりました。newaliasesすれば良さそうです。

 

2番目と3番目は手強そうなので、Geminiに助けを求めました。Geminiは、「その問題なら、こうすれば解決しますよ」とか気軽に応答するのですが、なかなか解決に至りません。しかも提示された解決策を試みるとエラーが出るので、それを報告すると、「すいません、間違っていました。本当は、この方法です」と別な方法を示してきます。生成AIの回答らしいと言えば、そのとおりです。その分野のエキスパートに尋ねても、やっぱりこうなるかもしれません。生成AIなら、現実の人間と違って、何度訊き返しても嫌がったり怒り出したりする心配がないのは、メリットのような気がします。

 

Geminiとの対話を2時間ほど費やしたあげく、なんとか解決に至りました。いろいろ試したし、試行した内容を取り消したりもしたので、混乱しましたが、次のような対策を講じました。

1. /etc/mail/ホスト名.submit.mcに「FEATURE(`msp', `[127.0.0.1]', `MSA', `E')」を追加した。
2. /etc/mail/ホスト名.mcに「DAEMON_OPTIONS(`Name=IPv4, Family=inet, Modifiers=b')」と変更した。IPv6の方も同様に変更した。

 

このように変更してsendmailサービスを再起動すると、溜まっていたメールが流れる「はず」だったのですが、溜まったままでした。Geminiも半ばお手上げ状態で、スプールにあるメールを「tr -d '\r'」しながら、senmailに渡し、強制的に配送しました。これが成功したので、スプールにあるファイルは物理的に削除しました。

 

そもそも、何故このような事態に陥ってしまったのか、その原因は不明です。前回と今回の問題解決において、Gemini（というか生成AI）の威力を実感しました。それと同時に、間違い（勘違い？）を含む回答もしてくるので、Geminiの回答を鵜呑みにするわけにはいかないだろうと思います。そういう意味で、Geminiの指示に淡々と従うわけにはいかないでしょう。生成AIがあれば、何も勉強しなくても万々歳とはならないと思います。 

BIMI-Indicator

自宅では、FreeBSD/amd64を使用してメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSで読んでいます。つい最近になって、ふと気づくと/var/spool/mqueueに配送できなかったメールが溜まっていることに気づきました。

 

溜まっているファイルを確認したら「SMTP error: 552 5.6.0 Headers too large (32768 max)」というエラーが記録されています。他のファイルも同様でした。このメッセージを手掛かりにWebを検索してみたのですが、解決に至る情報がみつかりませんでした。そこでGeminiに助けを求めてみました。

 

Geminiとの対話では、このメッセージを提示するところから始めました。これだけの情報では、一般論しか返ってこないので、対話を繰り返しながら、問題が解決できるような方向に話を進めました。解決策は幾つかあるようです。これまでは、上述したように、fetchmailで取り込み、.forward経由でprocmailを呼び出して振分けていました。.forwardを利用することでsendmailが介入することになりますが、問題となっているメールには「BIMI-Indicator」という巨大なヘッダがついていて、これが根本的な問題だろうと思います。

 

メッセージが指摘するように「Headers too large」なので、sendmailが「32768 max」という制限をかけているのを緩和するのも一つの方法です。他の方法として、fetchmailから直接procmailを呼び出すこともできて、そうすれば.forwardを使わないので、sendmailが介入することもありません。こちらの方法を採用することとして、.fetchmailrcに設定を追加しました。

 

対策を講じたことで、問題は解決したようです。

 

本来であれば、巨大な「BIMI-Indicator」というヘッダをつけている送信元が対処して欲しいところです。サイトのメールサーバの設定によっては、32kで制限をかけているところがあるでしょうから、そこでも問題が発生しているのではないかと思います。

Windows11のメディアプレイヤーでCD情報が表示されないのはspecificationなのかundocumented featureなのか

2025年12月初め頃から、Windows11のメディアプレイヤーにおいてCD情報が表示されなくなっているという報告がありました。Microsoftからは公式アナウンスが出ていないようなので、偶々何かの調子が悪いだけなのか判断できませんでした。2026年に入ってからは、Web上に次のような情報があります。あいかわらずMicrosoftから公式発表がないので、憶測でしかありません。

• 仕様が変わった？ Windows Media Playerやメディアプレーヤー、CDの楽曲情報取得が不可能に 
• Windowsメディアプレイヤーに異変→まさかの機能終了に惜しむ声「やっぱり不便」「乗り換えですかね…」 

 

なぜMicrosoftが公式に何も発表しないのかわかりませんが、そもそも「仕様」だったのだろうかという疑問をもちます。MicrosoftがWindowsを開発するにあたり、社内的には何らかの仕様書が存在する（はずだと思いますが、さすがに）のでしょうけれども、それが外部に伝わることはありません。私自身としては、Microsoft Windowsの一人のユーザとして、「Windows仕様書」というものは、これまでに見たことがありません。「ウィンドウズの使い方」のような文書なら見たことがありますが、それは「仕様書」というほどのものではなくて、「このような使い方がありますよ」という簡単な説明でしかありません。

 

メディアプレイヤーを使うとCD情報が表示されるということは、昔から気付いていましたが、それが「仕様に基づく」のか「偶々そうなっているだけ（実は何かのバグ？）」なのか、はっきりした説明を受けたことはありません。暗黙のうちに、CD情報が表示されるのが「仕様ではないか」と思い込んでいただけなのかもしれません。むしろ「undocumented feature」だったのかもしれません。

 

「仕様」だったのであれば、Microsoftに対して正式に説明を求めることができるとおもいます。しかし「undocumented feature」なのであれば、Microsoftに問い合わせても「そのような挙動が過去にあったとしても、メディアプレイヤーの機能の一部ではありません」と回答されて終わりになってしまうでしょう。

 

遥か昔にTK-85で8085を学んでいたころ、16x16のマトリクスで示されている命令一覧において、空白（未定義）となっているところにも、面白い動作をする「未定義命令」が隠してありました。しかし正式な命令として仕様書に記載されていたわけではありませんから、正式に問い合わせても（そんなことをした経験はありませんが）、正式に「知りません」と回答されるのがオチでしょう。

 

閑話休題。メディアプレイヤーが、今後もCD情報を表示しないのか、突然復旧するのか、皆目見当もつきません。僕個人の対策としては、Apple iTunesをインストールすることにしました。Windows10の頃には使用していましたが、Windows11に移行するにあたり不要かと考えていました。手持ちの音楽CDをメディアプレイヤーで再生できないわけではありませんが、CD情報が出ないのは、多少気になります。そのためだけにiTunesを利用するつもりです。 

 

 

findコマンドのオプション「-newerXY」

U*IXでは、BSD系でもLinux系でも、階層的なディレクトリ構造を辿ってファイルを見つけるには、findコマンドを使うのが標準的です。もっともオプションの指定方法が独特なので、昔から使い慣れているオプション以外は、よく知りませんでした。それでも、今まで特に困ったこともなかったのですが、これまで使ったことのない便利なオプションが（何時の間にやら）追加されていたことを知りました。

コマンド実行時点を基準に、指定した日付よりも以前とか以後のファイルを見つけるには、オプション「-mtime」を使えばよいと思っていました。また指定されたファイルを基準に、それよりも新しいファイルを見つけるには、オプション「-newer」を使えばよいと思っていました。これだけでも不自由はないのですが、オプション「-newer」では基準となるファイルを用意しておく必要があるので、もっと便利な方法がないだろうかと思っていました。

 

Webを検索したら、オプション「-newerXY」というものがあるようです。これは何だろうと調べてみたら、いくつか記事が見つかりました。

• findコマンドで期間を指定した検索をする 
• find コマンドがめっちゃ便利だった話 

 

このオプションは昔は無かったと思うので、いつの間にか追加されたのだと思います。これを使えば、オプション「-newer」のようにファイルを用意しておかなくても、特定の日時を基準にしてファイルを見つけられるようになります。素晴らしい。

 

findに限らず、よく利用しているコマンドにおいては、使い慣れたオプション以外に何があるのか改めて確認したりすることがありません。もしかすると便利なオプションが増えているかもしれないので、ちゃんとマニュアルを確認しておく必要があると思いました。

NHKラジオに「Enjoy Simple English」という英語教育番組があり、数年前から聴いています。テキストも購入しています。2025年10月から2026年3月までの放送は、2021年度上半期の再放送です。

 

2025年1月15日放送は、「Marie the Scientist」というシリーズにおける「Why Do People Die?」という内容でした。この冒頭は、次のように始まります。

Narration (Marie): Dear Diary, Today, Ms. Sato, our homeroom teacher, didn't come to school. So Mr. Fujita taught our class. Haruto asked Mr. Fujita ...

Haruto: Do you know where Ms. Sato is?

Mr. Fujita: She had some bad news. Her mother died last night.  

 

この部分は、学級担任の佐藤先生の代わりに藤田先生が現れたので、ハルトが「佐藤先生は、どうしたんですか？」と聞いているところです。このような状況は、学校に限らず、何処ででもあると思います。

 

ただし、ここで気になるのが「Do you know where Ms. Sato is?」という英語表現です。直訳すれば「佐藤先生が何処に居るか、知っていますか？」となるでしょう。意訳すれば「どうして来ないんですか？」とかなるところでしょう。

 

以前にも紹介したことがありますが、Japan Timesの週刊ST（2012年4月6日号）の連載「English across Cultures」（青山学院大学名誉教授 本名信行）の中に、次のような記述があります。

一つの例を挙げましょう。ある会合に、出席する予定だった人が来ていなかったとします。後日、その人に尋ねるとき、日本人は「私はあの会合に行きましたが、あなたはどうして来なかったのですか」と言います。これを英語にすると "I went to the meeting. Why didn't you come?" となります。ところが、ネイティブスピーカーは、こういう状況では、"I was there. Where were you?" というような言い方をします。同じ状況を、ネイティブスピーカーは動きではなく、存在としてとらえるのです。

 

これはまさに、上述した会話と同じ状況です。日本語でも英語でも、発想は「何某は何故居ないのか？」であったとしても、言葉で表現すると、日英で異なってしまうようなのです。この事実は、日本人が英語を学ぶ際に引っかかるところだと思います。日本人の表現を英語に直訳しても、それが英語圏で通じないということはないでしょう。しかし英語圏の表現の仕方を踏まえて英語で表現すれば、よりスムースな会話になると思います。

 

英語を勉強する中で、このような日英の表現の違いというものは、気にしなければならない必須事項ではないと思いますが、注意を払っておく方が良いのではないかと、私自身は考えています。本件に限らず、日英の表現の違いがあると思いますので、英語に接する際には注意してみていこうと思います。

JRE POINT IDとJRE IDは違う

JR西日本がSMART ICOCAのサービス終了をアナウンスしており、代替となるサービスを検討しています。いまのところ候補となっているのは、JR西日本の「モバイルICOCA」か、JR東日本の「モバイルSuica」です。どちらでも構わないのですが、まずはモバイルSuicaを試してみようと思います。

 

まず最初に、スマホが対応しているのかを確認しておきます。僕が使っているのは「Redmi Note 10T」です。これは「モバイルSuica・PASMO対応機種一覧掲載.pdf」に掲載されていますので、大丈夫です。

 

これまでは「おサイフケータイ」を使ったことがありませんでした。スマホにはアプリが入っているので、起動し、初期設定を済ませました。

 

次に「モバイルSuicaをはじめる」の手順に従い、作業します。最初にアプリをダウンロードし、それを起動します。ここで「JRE ID」へのログインが必要なのですが、気が付いてみれば些細なことだったのに、大きく躓いてしまいました。既にIDを持っているならログインするのですが、ログインしようとすると「IDかパスワードが間違っている」というエラーになります。そんなハズはないと思い、パソコン側でログインしてみましたが、問題なくログインできます。しかしスマホではログインできません。入力ミスなのかと、目を皿のようにして確認しましたが、入力を間違えていないようです。

 

スマホの画面には「ログインできない場合」の情報がリンクされていました。それを辿ってみたら、「JRE IDはJRE POINT IDとは違います」という情報があり、ここで目が覚めました。僕が入力していたのは、「JRE ID」ではなく「JRE POINT ID」だったのです。

 

「JRE ID」を新規作成してもよいのですが、2026年2月には「JRE POINT」サイトでも「JRE ID」が利用可能になるようです。それまで待ってから、続きを作業しようかと考えています。 

PDF24 Toolsでしおりを一括定義するためのスクリプトを試作

PDF24 Toolsを使うと、JSON形式のファイルを読み込ませることで、しおりを一括定義できることを知りました。JSON形式なので、普通のエディタで編集できるのです。しかし、しおりとして必要な情報以外に、JSON形式とするために必要な構造としなければなりません。簡単なスクリプトを組んで、JSON形式ファイルを生成してみました。ただし試作版なので、最低限のことしかできません。誰もが使えるツールという訳にはいきませんが、作業の省力化には役立ちそうです。

 

 #!/bin/sh

genJSON () {
    echo "["
    while IFS=, read x y; do
        echo "  {"
        printf '    "title":"%s",\n'     "$y"
        printf '    "dest":[%s,"Fit"]\n' "$x"
        echo "  },"
    done
    echo "]"
}


cat <<*EOF* | genJSON
3,Table of Contents
5,SPECIFICATIONS
8,MODULE FUNCTIONS
*EOF*
#[EOF]

PDFの「しおり」を一括登録したい

PDFのページに与えられている「しおり」を編集する方法を模索しています。Windows11にはPDFgear 2.1.12というアプリを入れてあり、しおり編集機能があります。しかし、既存のしおりを「一括削除」できないようなので、一つずつ削除するのは大変です。何とかならないかと思って調べてみました。

 

PDF24 Toolsというオンラインで完結するツール群があるようです。この中にある「PDFのブックマークを編集」を使えば、一括削除できそうです。

 

これで一件落着と思ったのですが、しおりをJSONファイルに保存したり、指定したJSONファイルに従ってしおりを定義したりすることができるようでした。このJSONファイルの形式が、PDFのしおり編集として一般的に使われているのか、PDF24 Tools独自なのかはわかりません。しかしJSON形式は、普通のエディタで編集できますので、手作業でしおりを追加していくよりも便利ではないかと思います。

 

意外なきっかけで、面白いツールに巡り合いました。 

TW5のdaysオペレータの挙動を類推する

TW5のdaysオペレータの挙動を、記事「Days Operator and Examples (documentation addition)」や「Filter tiddlers by date: today and in the past」を熟読したり、TW5上で実際の動作を確認したりして、類推してみました。

• デフォルトではフィールド「modified」を対象とするが、サフィックスで任意のフィールドを指定できる。
• 日付は、「Date Fields」に記されているように、「YYYYMMDDHHMMSSCCC」という17桁の数字列で表現される。
• 日時は、ローカルタイムではなく、UTCとして扱われる。
• days[N]は、N日後以前のTiddlerを得る。
• !days[N]は、N日後以降のTiddlerを得る。
• days[-N]は、N日前以降のTiddlerを得る。
• !days[-N]は、N日前以前のTiddlerを得る。
• days[0]は、今日だけのTiddlerを得る。
• !days[0]は、今日以外のTiddlerを得る。

 

このような挙動だとすると、今日以降の一週間以内のTiddlerを得るには「!days[1]days[6]」のように指定するのではないかと思います。ただし境界となる日を含むか否かを考えれば、Nの指定は別の値になるかもしれません。

 

daysオペレータは手強いと思いますが、なんとかなりそうな感触が得られたので、TWCからTW5に以降する作業を進められそうです。 

手荒れとしての汗疹や霜焼けが改善

10年ほど前には、手荒れが酷く、夏は汗疹、冬は霜焼けに苦しめられていました。あまりにも症状が酷いので皮膚科の病院に行ってみたりしました。通院していたのは短期間でしたが、それ以降、毎日薬用ハンドクリームを塗るように心掛けてきました。

 

すぐに効果がでたとは思いませんし、数年前までは、汗疹にも霜焼けにも苦しめられ続きました。

 

しかし昨年夏には酷い汗疹にはなりませんでした。また今冬は霜焼けになっていません。ようやく手荒れが直ってきたような気がします。 

feedlyがダウンしている

RSSフィードを利用するためfeedlyを利用しています。GoogleがRSSサービスを廃止した時に乗り換えました。基本的な動作に不満はないのですが、たまにサービスが利用できなくなるのが困りものです。2026年1月10日現在、サービスがダウンしているようです。Webを検索すると、同様の障害が報告されています。

• Is Feedly down?
• Feedly 炸了，本次作战代号 500 
  

 

しばらくすれば復旧すると思いますが、すぐに直るのか、しばらくかかるのか不明です。このような事態が、頻発しているとは言いませんが、全くないわけではなく、一年に何度かあります。

 

feedly以外にもRSSサービスがあるので、別のサービスに乗り換えた方が良いだろうかと思うこともあります。しかし別のサービスが安定しているとも限りません。別のサービスを使うことが問題解決になるとは考えられません。ともかく復旧を待とうと思います。 

SMART ICOCAのサービスが終了する

JR西日本が「20年間、ありがとう。次のスマートは、モバイルICOCAで。」という発表をしています。2026年10月31日をもってSMART ICOCAによるクイックチャージを終了するそうです。私自身はSMART ICOCAを持っていて、クレジットカードでチャージしています。今年11月からはクイックチャージ出来なくなるので、何か代替方法を探す必要があります。

 

JR西日本としては「モバイルICOCA」に移行して欲しいようです。それが最も正統なのだと思いますが、他の交通系ICカードを選択することもできると考えています。全国各地の交通系ICカードを何か持っていれば、個々にサービスの違いはありますが、基本的に鉄道運賃の支払いは可能ですから、ICOCAに拘らず、KITAKAだろうが、SUGOKAだろうが、何でも構わないと思います。ただし僕自身の条件としては、JRが指定するクレジットカードではなく、任意のクレジットカードでチャージできることです。それが、今までならSMART ICOCAでした。

 

僕の希望を満たすのは、「モバイルICOCA」か「モバイルSuica」が選択肢となりそうです。どちらを選択しても良いと思いますが、少なくともスマホにアプリを入れる必要があります。さらにスマホで「おサイフケータイ」を使う必要があります。これまで「おサイフケータイ」を利用したことがないので、ちょっと心配です。

TW5のdaysオペレータは手ごわい

これまでTiddly Wiki ClassicにReminder Pluginを入れてToDoリストのようなものを構築していました。今はTW5を利用しているので、TWCからTW5に移行しようと考えています。ところがプラグインのTW5版が見つからないので、同等機能をTW5で実現する必要があります。

 

実現方法の詳細は分からないのですが、daysオペレータが使えるのではないかと当たりをつけ、その挙動を調べてみました。しかし手ごわいです。僕の使用目的が、このオペレータの本来の目的とは違うのだろうと思います。僕としては、ある日を基準として、それから1週間以内とか、1か月から3か月以内などの期限日を持つTiddlerを一覧したいのです。

 

このオペレータの挙動が良く分からないので、Webを検索して見つけた情報の中から「Filter tiddlers by date: today and in the past」という情報が参照されていました。この情報は2016年頃なので、もう10年ほど前のものです。この中に次のようなことが書かれていました。

last 5 days:
<<list-links '[days:due[-5]!days:due[-1]sort[due]]'>>
next 5 days:
<<list-links '[!days:due[1]days:due[5]sort[due]]'>>

daysオペレータは、このように利用すればよいのかと思いましたが、手ごわいとも感じました。それはともかくとして、これで何とかなりそうです。

TWCからTW5に移行するために必要なReminder Plugin代替策

普段からTiddlyWikiを活用しています。使い始めたころは、今で言うところのTWC（TiddlyWiki Classic）でした。現在はTW5を主に使用しており、TWCの頃のTiddlyWikiはTW5に置き換えるようにしています。基本的にはTWCの情報をTW5に移すだけなのですが、ひとつだけ「TiddlyWiki Reminder Plugin」を利用しているものがあり、移行できずにいます。

 

TW5にも同等のプラグインがあれば良いのですが、今のところ見つけられていません。もっともプラグインの機能を全て使いこなしているわけではないので、同等機能をTW5で実現するだけで構わないと考えています。必要な機能としては、特定の日付を期限とする事柄をTiddlerとして用意しておいて、その1週間前とか1か月前などのタイミングで該当するTiddlerを列挙したいのです。ToDoリストのようなものです。

 

実現方法を考えているところですが、「days Operator」を利用すればよいのではないかと思っています。試しに使ってみましたが、挙動がよくわかりません。TW5の機能を実現しているJavaScriptは「$:/core/modules/filters/days.js」のようです。処理は短いものの、TW5の内部構造などに精通していないと、ロジックを理解できません。

 

情報を求めてWebを検索したところ、「Days Operator and Examples (documentation addition)」という2018年9月7日付の投稿を見つけました。もう10年弱ほど前の情報ですから、現状では変わっているところがあるかもしれません。しかし他に何か別の適切な情報のあてがあるわけでもないので、これを読むところから始めたいと考えています。