wslttyからWindows Terminalに乗り換えた話 & ターミナルへのドラッグアンドドロップでWSL版のパスが入るようにした
WSLの端末エミュレータとして長年 wsltty を愛用してきましたが、先日特に前触れなくwslttyが突然起動しなくなるという不具合に見舞われました。この症状自体は何度か経験があり、以前はwslttyの再インストールなどで治っていたのですが、今回は色々試しても治りませんでした。
調査したところ、公式Githubのissueに似たような報告があり、Githubのトップページには以下のような記載があるではありませんか！
Wsltty does not seem to work with WSL V2 mode since release 2.0.0 (#343). As a workaround until a solution in the wslbridge gateway, it is suggested to install release 1.3.17
WSLをダウングレードするのはさすがに憚られたので、他の端末エミュレータに乗り換えることを決意しました。
Windows Terminal への乗り換え
続きを読むiPadのPDF Viewer無料版で本を右綴じで読む方法
iPadでのPDFビューワーはもっぱらSideBooksを使っていましたが、業務用と個人用でアプリを分けたいと思いたち、Redditで評判の良かったPDF Viewer Pro by PSPDFKitを使い始めました。なかなか使い勝手が良かったのですが、無料版では本を開く方向を右綴じに変更できない点が難点でした。
有料版だとできるのですが、私がサブスクサービスを蛇蝎のごとく嫌っていることもあり、なんとか無料版で右綴じにできないか調べてみました。
解決方法
続きを読む衝突しないランダムな12桁のIDをより安全に払い出す方法
Chrome Native Messagingのホストからsubprocessを呼ぶ際の注意点
最近は趣味でChrome拡張機能の開発を行っていますが、Native MessagingのホストであるPythonプログラムから subprocess.check_call を実行すると、直後に実行中のTkinterウィンドウが閉じてプログラムが終了するという現象に見舞われました。最初は何らかのヤバイ例外が発生して親プロセスもろとも異常終了したのかと思いましたが、確認してみるとsubprocessから実行した処理は正常に終了しています。はて……？
原因はsubprocessの標準出力を捕捉していないことでした。 subprocess.run などのメソッドはデフォルトで stdout=None 、つまりリダイレクトを行わない設定となっており、生成されたプロセスは親プロセスと同じ入出力ストリームを使用します。ここで、Chrome拡張機能とNative Messagingホストは標準入出力を用いてメッセージのやり取りを行うため、子プロセスの出力もChrome側に送られてしまい、異常なメッセージと判断されコネクションが切断されるようです。
というわけで対処法としては、適切に標準入出力を捕捉してやればOKです。
cp = subprocess.run(
...,
stdin=subprocess.DEVNULL,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
)
self.log(cp.stdout.decode())
こんな感じ。完全に標準出力を捨てるなら stdout=subprocess.DEVNULL でよいですが、一応取得して self.log で出力するような感じにしました。また、使わないなら stdin も念の為 subprocess.DEVNULL にしておいた方が良いでしょう。
ちなみに親プロセスの Tkinter.Frame ウィンドウが閉じた理由は、単純に切断時にウィンドウを閉じる処理がコピペ元のGoogleのサンプルコードに組み込まれていたからでした。
余談ですが、Chrome Native Messagingのマニフェストに指定した大元のWindowsバッチファイルから @echo off を削除すると、コネクションが確立した瞬間に切断されるようになりました。今まで全然意識していませんでしたが、コマンドプロンプトのECHOが <ON> の場合のエコーバックって標準出力に吐いてるんですね。言われてみたらそうか。
さらばEvernote、俺はPaperless-ngxで行く
先日、2024年3月26日をもってEvernote Legacyが廃止されることが発表されました。発表によるといまだEvernote Legacyを使っているユーザーは全体の1%とのことですが、まさしくその1%に入っていた身としては青天の霹靂です。
Evernoteは2016年から長い間課金ユーザーでしたし、現時点でEvernote Personalのライセンスも半年ほど残っていますが、最近めっきり良い噂を聞かなくなったこともあり、これを機に他のサービスへの乗り換えを決意しました。
私はEvernoteをノートアプリとしてではなく、もっぱらスキャンしたPDFファイルを格納する倉庫として使用していました。感覚的には全ノートの9割がスキャンしたPDFファイルだと思います。そこで似たようなことを行えるアプリを調査したところ、Paperless-ngxというアプリをセルフホスティングするのが良さそうという結論に至りました。試しに1か月ほど使ってみたところ、かなり良い感じでしたので紹介いたします。
- Paperless-ngxとは
- 導入方法
- Evernoteからのインポート
- Paperless-ngxでの書類の整理方法
- 他の端末からアクセスする
- その他の設定
- Paperless-ngxの（現状の）不満点
Alt+Tabでalt-ime-ahkがスタックする不具合を回避した
WindowsでのIME切り替えにalt-ime-ahkを長年愛用していたのですが、いつ頃からかAlt+Tabでのウィンドウ切替時に、たまに以降Altキーが反応しなくなるという不具合を踏むようになってしまいました。不具合が発生した場合Altキーを長押しすることで解決していたのですが、前触れなく発生するため地味にストレスでした。
それで色々調べた結果、AHKのスクリプトからalt-ime-ahkを削除して以下のコードを追加したところ解決しました。
#Include IME.ahk LAlt & F20::return LAlt::IME_SET(0) RAlt & F20::return RAlt::IME_SET(1)
解説ですが、まず LAlt & F20::return でAHKに LAlt キーをprefix keyとして認識させています。 F20 は何でも良いですが、Altキーとの同時押しが置換されるためまず使わないキーを設定しています。そのうえで、 LAlt 単独にキーリマップを設定することで、 LAlt キーが単独で押されたときのみ発生する処理を書くことができるという仕組みらしいです。
この設定に変更してしばらく使っていますが、今のところ特に困った点は出ていません。余談ですがAltキーの代替として左右Shiftキー単押しでIMEオン・オフというのも試してみましたが、右ShiftキーがEnterに近いためミスが怖かったり、大文字交じりの文をタイプする際に誤って左Shiftキーを単押ししてしまったりと少々気になる点があったため、やはり左右Altキーが現時点での私にとってはベストという結論に至りました。
なお、AutoHotKeyのバージョンは 1.1.37.01 です。
