昔の最近の出来事(2025.10)

2025/10/31

テレワーク。早めに終了。

調べ事。

2025/10/30

テレワーク。早めに終了。

GoogleのDoodleがハロウィン仕様のパックマン。ハロウィンは判るのですが何故パックマン? と思ったところ、1980年の稼働(日本では7月、アメリカでは10月26日)から45周年という事らしい。

2025/10/29

テレワーク。早めに終了。

先日のorg-modeで attachment: のファイルがHTMLエクスポートすると絶対パスになる件。 expand-file-nameで展開しているというのもあるのですが、他にも絶対パスになっている事をチェックしているようで、 ちょっと弄れば相対パスにできるという感じでは無さそうだったり。LaTeXの式をレンダリングした画像と 同じような扱いなのかと思いきや全然扱いが違ってて挫けました😓。

2025/10/28

テレワーク。早めに終了。

調べごとをして終了。

2025/10/27

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

2025/10/26

AM中に起床。

掃除したり洗濯したり。

現在開発中の Emacs31系のWindows向けビルドでは yank-media というクリップボード画像の貼り付けがサポートされる予定です。 org-modeでは貼り付けに対応しているのですが、.orgファイルに貼り付けた後にHTMLにexportすると 画像のリンクが expand-file-name で展開された絶対パスになってしまいます。 Cygwinビルドでは ewwで見るのは大丈夫ですが、EdgeやChromeなどの外部ブラウザを使用すると ファイルパスがCygwinパスになっている為、画像が表示されないという事が起こっています。 クリップボードから貼り付けた画像はデフォルトでは.orgファイルと同じディレクトリの dataという ディレクトリ内に保存されます。 画像の参照は「[[attachment:clipboard-20251026T121446.png]]」のような感じで、attachment:という 特別なキーワードと clipboard-yyyymmddThhmmss.* という形式の自動生成名から成り、 途中のパスは何かしら自動生成されるハッシュ値的な物(UUIDっぽくも見える)を使用しているようです。 HTMLにexportする際に 相対パスで「src=./data/.../clipboard-...」と記してくれれば良いのですが、 色んなところで expand-file-name で展開した絶対パス名を使用しているようです。 また、設定値の書き方とかで対応できる感じにもなっていないようです。 CygwinパスとWindowsパスの違いの問題もありますが、そもそも絶対パスだと 画像ファイルの置き場所を移動すると 表示できなくなってしまうし、公開Webページとしてアップロードしてもリンク切れになってしまうなど、 デメリットしか無いように思われます。なんとかならないっすかね?とは思ったりも。

minibufferでファイルパス名に文字「?」を入れようとしたら minibuffer-completion-help 実行にバインドされているなぁ? と思ったり。以前シェルのglobstarなるものを知り、 時々find-diredの代わりに使う事があるのですが、正規表現を少し細かく「**/*.??g」のような指定をしたい と思ったところ、文字「?」が入れられないので気づいた次第。 .emacsに「(define-key minibuffer-local-completion-map "?" nil)」を記して無効化する方向で。

2025/10/25

AM中に起床。通院。

Web巡回していたら、PlemolJPのv3.0.0が 今年の6月29日に出ていたというのに気づいたり。 元になっているIBM Plexの「IBM Plex Sans JP」 がv2.0.0になったのに追従したアップデートだった模様。グリフが大量に追加されているらしいですが、 異体字セレクタに対応している訳では無さげ。 因みに、IBM Plex Sans JP の方はv3.0.0が今年の9月2日に出ているようです (Releases @ibm/plex-sans-jp@3.0.0)。 また、IBM PlexはGoogle Fontsでもダウンロードできるように なっているっぽいですが、v1.001なのでちょっと古いのが置かれているようです。

2025/10/24

テレワーク。早めに終了。

Emacs30.2で zlc-modeの補完がうまく動いていない件。 29.4の lisp/minibuffer.el を読み込むと解消したので、30.2との差分を調べてみたところ、 なにやら余計なテキストプロパティが追加されるようになっているようです。 以下のようなパッチでひとまず機能するようになりましたが副作用があるかも知れません。

$ diff -u lisp/minibuffer.el.orig  lisp/minibuffer.el
--- lisp/minibuffer.el.orig     2025-03-15 22:19:26.000000000 +0900
+++ lisp/minibuffer.el  2025-10-24 19:31:05.140339100 +0900
@@ -703,12 +703,12 @@
                    ;; on the first character of the completion.  Make
                    ;; sure the quoted completion has these properties
                    ;; too.
-                   (add-text-properties 0 1 (text-properties-at 0 completion)
-                                        qcompletion)
+;                   (add-text-properties 0 1 (text-properties-at 0 completion)
+;                                        qcompletion)
                    ;; Attach unquoted completion string, which is needed
                    ;; to score the completion in `completion--flex-score'.
-                   (put-text-property 0 1 'completion--unquoted
-                                      completion qcompletion)
+;                   (put-text-property 0 1 'completion--unquoted
+;                                      completion qcompletion)
                   ;; FIXME: Similarly here, Cygwin's mapping trips this
                   ;; assertion.
                    ;;(cl-assert


しばらく普段使いで様子見してみよう。

パッチの差分を確認していたら、何故かdiffの日付表示に差分があって妙な時間を指しているなぁ? と思ったり。どうやら diff の 3.12 は変っぽい。

$ echo test_message > test.txt

$ ls -l
合計 1
-rw-rw-r-- 1 TANE-HP なし 13 10月 24 22:23 test.txt

$ /usr/bin/diff -u -N test.txt.orig test.txt
--- test.txt.orig       1970-01-01 09:00:00.000000000 +0900
+++ test.txt    1970-01-01 09:00:00.000000000 +0900              ★★★★日付が変
@@ -0,0 +1 @@
+test_message

$ /usr/bin/diff -v
diff (GNU diffutils) 3.12
Packaged by Cygwin (3.12-1)
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.


ファイルの日付が変になっています。
前に野良ビルドして使っていた 3.8 の場合は以下のような感じ。

$ ~/develop/work/diffutils/diffutils-3.8/src/diff -u -N test.txt.orig test.txt
--- test.txt.orig       1970-01-01 09:00:00.000000000 +0900
+++ test.txt    2025-10-24 22:23:11.567447100 +0900              ★★★★ファイルの日付通り
@@ -0,0 +1 @@
+test_message

$ ~/develop/work/diffutils/diffutils-3.8/src/diff -v
diff (GNU diffutils) 3.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.

3.12よりも新しいのは出ていないようなので、発見されていないか発見されていても 修正リリースは出ていないという感じ。3.8と3.12の間もいくつかバージョンがあるのですが、 どのタイミングで変になったのかまでは判らず。うーむ🤔。 当面 3.8にロールバックして 3.12よりも新しいのが出たらまた確認するという方向で様子見。

2025/10/23

テレワーク。早めに終了。

Emacs30.2で zlc-modeの補完がうまく動いていないのに今頃気づきました😓。 以前、31系では上手く動かなくなっているというのに気づいて lisp/minibuffer.el の方を対応するしかないなぁという事があったのですが、 その時の「候補文字列のテキストプロパティが無くなっていて、余計な文字列が補完される。」が 30.2でも起こっている予感。と思ったのですが、 テキストプロパティの中に変なプロパティが含まれているのが原因のようです。なんだこれ?🤔 29.4では大丈夫そうで、上手く動くようにした31系と同じテキストプロパティが返っているみたい。 30系で壊れてる感じになっていた模様。

2025/10/22

テレワーク。早めに終了。

今更ですが、bashの入力キーバインドに「C-/」でUndo ができるのを知りました。 因みにEmacsスタイルです。今まで押し間違いで存在に気づいたことは無かったので、 コマンドライン編集でUndoを期待するようなことは無かったのだと思いますに、 個人的にはあまり使う場面は無いかも知れません。

2025/10/21

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

2025/10/20

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

2025/10/19

AM中に起床。

掃除したり洗濯したり。

Emacsのキーボードマクロの中に isearchで W32-IMEから文字を入力するという要素を含めると うまくマクロ実行できないのを調べたり。キーボードマクロを調べると、 なにやら「with-keyboard-coding」というのが記録されていて、 ./lisp/international/isearch-x.el の中でそのキーコードを受け取ったら 関数isearch-with-keyboard-coding を実行するような事が記されているのですが、そもそも「with-keyboard-coding」というキーが どこに定義されているのか判らなかったり。どういう事?🤔

2025/10/18

AM中に起床。

ちょろり買い物にお出かけ。

あまり数がある訳では無いのですが、使用済みのボタン電池を回収してもらおうと持ち込んだ所、 雑にマスキングテープで包んでいたので穴に入らず一旦断念。それにしても資源ゴミ回収では コイン型のリチウム電池(CR2032とか)は回収OKらしいのですが、一般的にもよく使うと思われる LR44とかは回収しないというのがよくわかりません。
ボタン型電池を資源ゴミで回収しないのなんでだっけ?と調べていたところ、 川崎市では 2025年11月からリチウムイオン電池などの二次電池も回収するようになるのを知ったり (川崎市ページ)。 髭剃りなどは分解不要で回収してもらえるようです。ありがたや。 で、ボタン型電池は水銀を含む場合があるので回収しないという事みたい。 水銀フリーなボタン電池も存在するのですが、見た目で区別がつかないのでダメっぽい。

カラーシャープ芯。先週買った水色は薄すぎたので、 赤と青を購入してみました。色んな色入りってのもあったのですが、0.7mmのが無かったので試せず。 ついでにもう一本0.7mmのシャープペン本体も購入。今回買ったのは300円でまぁ普通。 赤も青も想像した通りの色の濃さだったので、あまり色分けすることはありませんが普段使いしてみようと思ったり。 それよりもシャープペン本体の色が 白と青で、白の本体は重いので青の本体をよく使うだろう色に した結果、青の本体に赤芯、白の本体に青芯 を入れました。が、絶対に一回は思ったのと違う色の方を選んで 「あぁ...💦」ってなる気がします😓

Emacsの テーマのカスタマイズメニューでは、チェックボックスの描画は絵文字フォントではなくて 画像で表示されています。何気に masterブランチ(31.0.50相当)のEmacsで表示しているのを見ると なんだかズレた位置にレンダリングされた画像になっているなぁ?と思ったり。 30.2ではそんな事になっていないので、何が違うのか調べようと思ったのですが、 どこで画像を選んでレンダリングして表示しているのかよく分からず。
どうやら lisp/wid-edit.el でwidgetとして管理されるっぽい。なのですが表示の実体は SVG画像を create-imageやinsert-imageでレンダリングしているようです。さておき、以下のような感じに見えます。


30.xでは大丈夫なので、何かが壊れていると思われます。
configureで svgサポートを外して(--with-rsvg=no)ビルドしたEmacsで確認してみたところ、 etc/images/*.svgではなく etc/images/*.xpmを使用して表示するようですが、 こちらでは特に問題は無さそうです。SVGでレンダリングする際の位置に問題がある感じなのでしょうか?

どうやら一部のSVGで描かれたアイコン画像のサイズ指定の問題っぽい? 例えば etc/images/checked.svg では高さの指定に「height="1em"」というのが使われています。 1emというのはフォント指定のサイズに対する相対的な値のようで、文字のサイズが16pxならば、 1emは16pxとして扱われる事になるようです。ここからは推測ですが、 Emacs内のSVGレンダリング時にフレームで表示しているフォントのサイズが指定されているようですが、 フォントサイズが指定されているのに加えて SVG画像の表示もサイズに応じてスケールするので、 二重にスケールしているのではないかと推測します。 30.2の時にはSVGデータの中に基準になるフォントサイズ指定が無いようですが、 31.xではフレームのフォントサイズが指定されるようになってっぽい。 という訳で、etc/images/*.svgの中で 1emを使用しているものを「height="16"」に変更すると、 意図通りにレンダリングされるようです。

2025/10/17

テレワーク。気持ち早めに終了。

そういえば先日知った超連射68kの Ver1.10 って、いつ頃出ていたのかしら? と思い調べてみたり。 超連射68kのページには 特に明記は無さそうで、クレジットは「©1995 1998」となっていたので、その頃に出ていたのかな? と思ったわけですが、ゲーム本体が X68000用の xdf形式で置かれていたので、エミュレータでxdfの中を 見てみたところ、CRS68K/DOC/readme.txt に 散逸していたソースとデータを2021年頃からサルベージした 事が記されていました。全てのファイルの日付が「2023-01-01 00:00」になっていたので、 それくらいにビルドされたのだろうと想像します。 Wikipedia によると、X68000 Z EARLY ACCESS KITに 同梱されていたようで、正確なリリース日は分かりませんが 2023年4月頃だったのだろうと思われます。 という訳で、Ver1.10が出たのは 2023年なので、約27年間気づかなかった訳では無い (2年くらいは気づいてませんでしたが😅)という事でした。

背景グラフィックが変わっていたりするのですが、リプレイデータは互換があるという事で、 大昔に草の根BBSで知り合った めっちゃシューティングゲームの上手い方の ウルトラ超絶プレイの リプレイデータを食わせてみたところ ちゃんと再生されました。

2025/10/16

テレワーク。気持ち早めに終了。

Web巡回して終了。

2025/10/15

テレワーク。気持ち早めに終了。

Windows Update。Emacsのハングテストを継続していたのを一旦終了させて Update後にテスト再開。

2025/10/14

テレワーク。早くもなく遅くもなく終了。

全然関係ない流れで見つけた 「【X68000】超連射68k Ver1.10【エンディングまで】」 という動画。ん?エンディングって何?と思って最後の方を観てみたところ、ラスボス倒した後に見たこと無い映像が。 そういや背景画像も見たことない感じになっていて、TANEが知ってるのはver1.00(SZ2.Xの日付は97-12-28 19:57) だったというのに今頃気づきました😅。

2025/10/13

AM中に起床。

NHK総合で「大阪・関西万博閉会式」を放送していたのをBGVで観たり。 結局GoogleEarthでは完成版は見られるようにならなかったですが、GoogleMapの航空写真は完成版になっていたようです。

そういえばGoogle検索で期間指定ができますが、終了日を過去に指定して古い情報を探そうとしてみたのですが、 フィルターが効いていないような気が。

2025/10/12

AM中に起床。

掃除したり。

ちょろり買い物にお出かけ。「これ描いて死ね(8)」捕獲。 気にはなっていた「カラーのシャープ芯」をどんなもんかと試しに購入。0.5mmのもあったのですが 0.7mmを選択。でも0.7mmのシャープペン本体は持っていないので本体も購入。 値段を見ていなかったのですが、シャープペンの方が825円だというのに後で気づいて驚いたり😅。 なんでこんなに高いんだ?と思ったのですが、振ると芯が出てくる機構が付いているものだったらしい。 でも手持ちの他のシャーペンは普通のなので振る機構は多分使わない😓。

カラーシャープ芯。水色を買ったのですが色が薄いな。下書きを消さなくても印刷に出ないという利点が あるようですが薄くてよく見えない😅。他の色も試してみたくなりました。

2025/10/11

AM中に起床。

そういえば gpt-ossのモデルって更新されてたりするのだろうか?と思い、 ollama pull してみたところアップデートされたり。pullできるという事は何かしら変わっているという事なのかしら? 「ollama show -v gpt-oss:20b」でモデルの情報を表示してみても、 モデルのバージョンに関する情報は含まれていないようなので、いつ時点のモデルを使用しているか?は判らない予感。 因みに ollama list で出てくる MODIFIEDは pullした時点からの経過時間を示しているので、モデルが更新された 日時が判れば pullした日付と合わせてどの時点のモデルを使用しているかを判別できるかも知れません。

2025/10/10

テレワーク。早くもなく遅くもなく終了。

CygwinパッケージのImageMagickが更新されていたので、インストールする前に同じバージョンで 野良パッチの確認をしたり。HEICフォーマットの色化けはバージョンアップで直る予定だったので そちらのパッチは不要になりますが、透明度付きグレースケールのTGAフォーマットは野良パッチとして 引き続き取り込む感じに。
で、ImageMagickをインストールしようと思ったところ、Cygwin本体も 3.6.5-1 が出ていたので、 インストール前に git pullでログの確認をしたり。pull前から2つの修正が追加されていたのですが Emacsハング修正には関係していなさげ。インストールしてみて一応ハング再現するか少し様子を見る方向で。 因みに gdb上でemacs-w32を動かすと謎のSIGTRAPが発生するのは変わりないようです。 後、先週から実行していたEmacsハング回避パッチの様子見では 約1週間 Emacsハングは再現していませんでした。

いくつかEmacsを立ち上げてパッケージオリジナルの Cygwin3.6.5-1 でハング再現の様子を見てみたのですが、 数時間でハング再現しました🥺。仕方ないのでワークアラウンドパッチを当てて野良ビルドしたcygwin1.dllと 入れ替えて様子見開始。まぁ大丈夫だろうと思いますが。

2025/10/09

テレワーク。気持ち早めに終了。

調べごとをして終了。

2025/10/08

テレワーク。早くもなく遅くもなく終了。

GIMP 3.0.6がリリースされているのに気づいたり (GIMP 3.0.6 Released)。 ちょろっと触った感じでは特に問題無さげ。安定してきている気も。

2025/10/07

テレワーク。早くもなく遅くもなく終了。

全く気付いていなかったのですが、magitでの「Tracked files」表示が途中までしか出てないようだったり。 以前、gptelを試すために Transientを更新した後、 magit-20230410.857ではダメになっている箇所があったので、magit-20250912.1136に更新しました。 以前のmagitではディレクトリの中は非表示の状態になっていて、展開したり折りたたんだりできたのですが、 現在のではサブディレクトリのファイルも含めて全て表示しようとしています。 しかし、100までしか表示されていない為、トラッキングしているファイルを探す事ができなくなっています。 なんだこれ?🤔
どうやら カスタム変数magit-status-file-list-limit てのが新しく定義されているようで、 この値がデフォルトで100になっている模様。ここを20000とかに設定すれば 5000以上のファイルがある Emacsのリポジトリでもトラッキングしている全てのファイルを表示できました。 「Tracked files (xxxx)」の行で TABキーを押せば展開したり折りたたんだりできるので、 全部表示するか 全く表示しないか の二択という感じになるようです。なぜ 操作仕様を変えたのかは不明。 パフォーマンスを理由にしているみたいですが、中途半端なリストを出されても役に立たないし、 リストが必要な人は パフォーマンスを理由にして リストの取得を諦める訳が無いと思います。 考え方が理解できません。

2025/10/06

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

Windows11の「ペイント」ってレイヤーを使えるようになってたのか。AI補助とか何気に色々変わっているっぽい。

2025/10/05

AM中に起床。

掃除したり洗濯したり。

ちょろり生活備品の調達。本屋に寄ったところ「アオイホノオ(32)」が置かれていたので捕獲。 31巻はなかなか捕獲できず (1, 2, 3, 4)、死に筋判定されているのか?と思ったのですが、置かれてたので タイミングの問題だったのか?と思ったりも。ただ、書棚には30巻はあるのに31巻は無かったので やっぱり31巻には何かあるのかも知れない😅。

2025/10/04

AM中に起床。

ノートPCで継続していたCygwinパッチの確認。合計で約3週間(478時間) 3つのEmacsを動かし続けて ハングしなかったのですが、先日副作用が見つかったので 一旦確認は終了。

Emacsハング対応のCygwinパッチ再考。 前のパッチは SIGALRM の場合は処理を完全にスキップするような感じでしたが、 スレッド数が1の場合は発動しないという条件を追加してみたり。 元々、複数のスレッドでロックが競合した場合に、何故かスレッドが切り替わらない為に ロックループがいつまでも脱出できないという動きになっていそうな感じでした。 ロックされていた場合はスキップするみたいなコードを入れてみたものの、 ロック状態確認とロック実行の間の時間を理論上0にする事ができない為、ハングしにくくはなるものの 完全対応にはなりませんでした。そこで、ダメもとで SIGALRMの場合は処理を完全スキップする としてみたところ(以前のメモ) Emacsはハングしなくなったのですが、 先日の alarm() を使ったコードでは SIGALRM が無限に保留される事となり影響があるのが分かった... という流れです。 で、そもそもシングルスレッドでは ロック競合は起こりえないハズなので、 最初に記した通りスレッド数が1の場合は発動しないという条件を加えてみたらどうか? と思った次第です。ワークアラウンドとは言え、 ひとつ前のコードと同様に「このパッチ、意図が分からん」に 拍車をかけている感は否めません😓。

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index f79978f73..bb45b0148 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -961,7 +961,7 @@ _cygtls::interrupt_now (CONTEXT *cx, siginfo_t& si, void *handler,
       if (!inside_kernel (cx, true))
        {
          HANDLE h_veh = AddVectoredExceptionHandler (0, singlestep_handler);
-         cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
+//       cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
          SetThreadContext (*this, cx);
          suspend_on_exception = true;
          in_singlestep_handler = false;
diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
index 1c9b8037b..799476e1f 100644
--- a/winsup/cygwin/mm/cygheap.cc
+++ b/winsup/cygwin/mm/cygheap.cc
@@ -743,6 +743,8 @@ init_cygheap::find_tls (int sig, bool& issig_wait)
   while (++ix < (int) nthreads)
     {
       /* Only pthreads have tid set to non-0. */
+      if (nthreads!=1 && (sig==14 || threadlist[ix].thread->locked () != false))
+       continue;
       threadlist[ix].thread->lock ();
       if (!threadlist[ix].thread->tid
          || !threadlist[ix].thread->initialized)

ひとまず、先日のalarm()を使うコードや diffutilsのconfigure実行は大丈夫となり、 Emacsの方はスレッド数が1では無いので、元々の SIGALRM時は処理をスキップする (3週間ハングしなかった実績のある)条件になります。 ただ、複数スレッドを起動して SIGALRMをハンドリングするようなプログラムでは依然として 何かしら副作用があるかも知れません。

という訳で、ノートPCで Emacsを3つ動かし続けて様子を見るテストを再開。 条件的にEmacsがどうにかなる事は無いハズなので、普段使いのデスクトップPCにも適用して様子見。

2025/10/03

テレワーク。気持ち早めに終了。

先日のCygwinパッチの副作用。configureでの検査の中で、以下のコードが終了しないという 感じになっていました。

     1  #include <errno.h>
     2  #include <unistd.h>
     3  #include <signal.h>
     4  static void
     5  handle_alarm (int sig)
     6  {
     7    if (sig != SIGALRM)
     8      _exit (2);
     9  }
    10
    11  int
    12  main (void)
    13  {
    14
    15      /* Failure to compile this test due to missing alarm is okay,
    16         since all such platforms (mingw, MSVC) also lack sleep.  */
    17      unsigned int pentecost = 50 * 24 * 60 * 60; /* 50 days.  */
    18      unsigned int remaining;
    19      signal (SIGALRM, handle_alarm);
    20      alarm (1);
    21      remaining = sleep (pentecost);
    22      if (remaining > pentecost)
    23        return 3;
    24      if (remaining <= pentecost - 10)
    25        return 4;
    26      return 0;
    27
    28    ;
    29    return 0;
    30  }

19行目でSIGALRMを受けた時のハンドルを設定し、20行目で1秒後にSIGALRMを送るように設定して、 1秒経つ前に 21行目でsleep()を実行という流れで、sleepは50日待つので alarm(1) が 機能していなければ50日後に先に進かも知れないけど 終了コード0にはならないという感じかと。 恐らくCygwinのパッチで SIGALRM の場合は処理しないみたいなコードにしているので、 SIGALRMが送られてこないというのにも辻褄が合っているとは思ったりも。
ただし、例えば「(./a ; echo $?)」で実行した後、Ctrl-Zでサスペンドして、 bgコマンドもしくはfgコマンドで動作継続すると 終了コードは0 になるようです。 先日のconfigure実行がバックグラウンドでエラーせずに先に進んだのとも辻褄が合います。 SIGALRM以外のシグナルを受ければ、ついでにSIGALRMも処理される感じなのかしら?🤔

2025/10/02

テレワーク。早めに終了。

何気に以前作成したdiffの -y のカラーパッチを 新しい diffutils-3.12 に対応してみたり。ところがconfigure実行で sleepのテストがいつまで経っても終わらず。 むむ、これはEmacsハングに対応する Cygwinへのパッチが 影響している気が。configure内で実行しているテストコードを切り出してコンパイル&実行してみたところ、 確かにいつまで経っても終わらないのですが、Ctrl-Zでバックグラウンドに切り替えてbgで実行継続すると 先に進むようだったので、本題のdiffutilsのconfigureはそれで進めたり。 ひとまずパッチ(diff-y_coloring_patch-3.12.diff.xz) を置きます。御参考まで。

Cygwinパッチの副作用が見つかったので 対応を考え直す必要があるなぁ....🤔

2025/10/01

テレワーク。気持ち早めに終了。

調べごとをして終了。


TOP PREV