@redbrick EUC-JPで持ってるメッセージを必要に応じEUC/Shift-JISで吐く作りになっているので、これをUTF-8でも吐かせるようにするとか何らかの手段が必要そうではありますね。
とりあえずまずは埃だらけのコードを掃除してからどうするかという気がします(量が多いので掃除もなかなか進まないのです)。
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
@redbrick EUC-JPで持ってるメッセージを必要に応じEUC/Shift-JISで吐く作りになっているので、これをUTF-8でも吐かせるようにするとか何らかの手段が必要そうではありますね。
とりあえずまずは埃だらけのコードを掃除してからどうするかという気がします(量が多いので掃除もなかなか進まないのです)。
このアカウントは、notestockで公開設定になっていません。
昨日いじった部分をPRの変更部分見ながら確認してみたけど、signal周りの大ポカ(さっき直した)を除けば問題ないと思う。backportでも動作を確認できてるし…
それで思い出したんだけど、sj3自体はja_JP.EUCでメッセージを吐くとして、その上で動くbashがja_JP.UTF-8でメッセージを吐くので割と困ったことになるんですよねえ…
onwinchの先頭でsignal(SIGWINCH, SIG_IGN)してることに気づいてないぞ自分💢
とりあえず、Vine2.5上の挙動を信じられるかという話はあるだろうけど…目の前でこういう現実があった以上、SA_RESETHANDあり/signalハンドラ内での再設定あり、でやるしかなさそう…
LinuCのSysV風サンプルではSA_RESETHANDを使ってない(のでhandler()内でもsignalの再設定はしていない)。
http://linuxc.info/signal/signal3.html
だからまあSA_RESETHANDは無いってことで良いはずなんだが… 流石にSA_RESETHAND周りのsigaction()に問題があるとかそういう話は無いと信じたい。
Vine2.5上でonwchichのハンドラ再設定を止めると、ちゃんと動かない(ウィンドウサイズの変更に追従しない)。sigactionでSA_RESETHANDは宣言してないんだけど、どゆこと?
done, makecore, exitprocess, fail→exit()なりabort()なりを呼ぶ
sigpipe→動作中はSIG_IGN、終了後は元の物に復帰
sigtstp→一旦SIG_DFLを設定し、pid=0宛にSIGTSTP送信後保存しといたold_sigtstpのハンドラを復帰
onwinch→ハンドラ抜ける際に再度onwinchのハンドラを設定
posix signal化してるのでonwinchのハンドラ再設定は要らないよね??
SIG01-C. シグナルハンドラの継続性に関して処理系定義の詳細を理解する (2020-06-16) https://www.jpcert.or.jp/sc-rules/c-sig01-c.html
このアカウントは、notestockで公開設定になっていません。
sj3.c、suspend()のioctl(master, TIOCOUTQ, &nc) < 0の時の処理がちょっと分からないんだけど、SVR4ではループを抜けて後始末、それ以外ではfail()に飛ばして後始末をせずにkill(SIGTERM)というのは…どっちが良いんだろう。とりあえず非SVR4な扱いにしちゃってるけど。
なんかこの子プロセスにまつわる扱い、ヤな問題を抱えてそうな気がするんだけど…SVR4/BSD/Linuxで何か挙動が違うんだろうか。歴史的なことを知ってるUNIXプログラマの助言が欲しい。
sj3,.c: SIGCHLDに対するsignal()/sigaction()の設定タイミングがSVR4だとfork()後、それ以外ではfork()前になってるんだけどこれどういうことなんだろう。とりあえず非SVR4ということでfork()前にしちゃったけど。
ああああああ、sigpipeの扱い方がめちゃくちゃになってる。これは直さないと(何故ああ書いたんだ自分)
ぬおおおお、sj3(原典)のMakefileって*.bakを消すようになってる…なんてことを…
で、あればかなり大掛かりな修正にしちゃってるけど大筋は問題ないっていう判断でいいかな?できればBSD系のふっるいOSでも試してみたいところなんだけど(とはいえopenpty使ってるとなると古いOSと言えどそこそこ新しいものになるはず)。
PRで投げたsj3(tty frontend)の修正、sj3.hも含めて原典にbackportしてみたけど一応動いてる感じです。ていうか動くんだこれ…
もしかして、sj3.hが(こっちで勝手に追加した)Func.hに相当する物だったりする?(ということはsj3.hへ統合しちゃうのが適切かな)
2023年は「DOS/V」の終焉 (2023/12/30) https://pc.watch.impress.co.jp/docs/topic/feature/1558548.html
一つの時代が終わったのか…
Windows 3.1日本語版の仮想環境を比較 (2022年版) (2022-01-29) https://diarywind.com/blog/e/win31j-on-vm-2022.html
表題はWindows3.1となっているけど、DOS/Vへの言及もあり。
https://iosoft.blog/2020/07/16/raspberry-pi-smi/ ふむふむ…「全てのRaspberry PiにSecondary Memory Interface (SMI)が含まれているが、公開されているドキュメントが無いので滅多に使われてはいない。筆者の見つけた唯一の情報は https://github.com/Ysurac/raspberry_kernel_mptcp/blob/master/include/linux/broadcom/bcm2835_smi.h と https://github.com/fenlogic/IDE_trial 」(雑な訳)
Broadcomのいつもの秘密主義か…というのが最初に思った感想。とはいえ他のSoCメーカーも情報出してくれないことがあるしBroadcomばかり悪く言うのは良くないか。
このアカウントは、notestockで公開設定になっていません。