[FDclone-users:00911] Re: FDclone 3.00i has been released

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

　一時はどうなることかと思いましたが無事 3.00i 出ました。

In Message-Id <20100723172326.440A24806C4@yuka.unixusers.net>
        Takashi SHIRAI <shirai@unixusers.net>writes:
> 　しらいです。

> 　以下は HISTORY より今回の変更点の抜粋です。

　今回かなり変更点が多くなりました。HISTORY に載ってるだけで
15 個ですか。[FDclone-users:00909] で code freeze 宣言してま
すが、「もう bug 見つかるな！」という心の叫びも入ってました。
　ML 以外からの bug 報告もあるし、debug 中に違う bug を自分
で見つけることもあります。ある程度落ち着かないと、bug 抱えて
るのを知りながら release するのは心苦しいですし。

　という訳で変更点が多いと解説も結構大変です。気合い入れて書
いたら 13KB 超の大作になってしまったので、読む方にもそれなり
の気合いが必要になりそうです。


> 	MINIX 3 対応。

　[FDclone-users:00883] に始まる thread の話です。HISTORY 上
の記述はあっさりとしたもんですが、ボリューム的には今回の変更
点の中で一番多くを占めている要素ですね。
　machine.h の識別子で対応した箇所に関しては TECHKNOW で解説
してるのでそちらを参照して下さい。今回新設された識別子は全て
MINIX 用ですが、識別子での対応分だけで 9 個もあります。
　これ以外の変更では、おさらいになりますけど大きなもので以下
のようなものが挙げられます。

・MINIX 固有のヘッダ操作
　<minix/minlib.h> を足したり <netinet/ip.h> を引いたりして
います。

・getmntent(3) の独自実装
　/etc/mtab を直接見るしかないのでなかなかに面倒でした。

・send(2) の削除
　send(2) って存在してるだけで機能は実装されてないそうです。

・job control の削除
　MS-DOS と同レベルに job 非対応にしました。

・/dev/tty の代わりに STDIN の複製を使用
　STDIN は redirect せずにお使い下さい。

・gettimeofday(2) の第二引数を NULL に
　何故か man page にそうしろって書いてあります。

・PTY slave を閉じない実装に
　これは MINIX 以外の環境にも採用した変更点ですが、特に弊害
も無さそうです。


> 	NetBSD 5.0 対応。

　すっかり忘れてるかも知れませんが [FDclone-users:00868] に
始まる thread の話です。NetBSD もなかなかにややこしい OS に
なって来ましたね。ソースも昔はもっとすっきりしてたのに。


> 	仮想ファイルシステム上のディレクトリ移動を許可。

　smbnetfs という仮想 file system があるそうです。所謂 smbfs
なんですが、こいつを使うと getcwd(3) が失敗します。directory
tree が破綻してて親子間の繋がりが切れてるんですよ。
　で、getcwd(3) が失敗した場合に、これまでの CWD の経緯から
論理的な CWD を生成してそちらを採用する形に改めました。なの
で、起動時から CWD がそんなところにあった場合はアウトです。

　bash や ash は環境変数 PWD を参照していて、getcwd(3) の結
果よりそちらを尊重しているお蔭で、そういう仮想ディレクトリ上
で起動しても問題なく CWD を保持し続けられます。
　しかし、これって PWD の値を偽装して shell をだますことも出
来てしまう訳で、利便性よりも危険性の方が大きいんじゃないかと
思います。
　なので、FDclone では getcwd(3) の結果と実体が一致する場合
のみ PWD の値を採用する仕組みになっています。これは従来から
の仕様です。

　因みに getcwd(2) という実装もあって、例えば Linux 辺りがそ
うなんですが、こっちだと CWD は kernel が逐一管理しているの
で directory tree が破綻してても何とか食い繋げます。
　getcwd(3) の場合は、「.」と同じ i-node を持つ「..」の子を
探して自分の sub directory 名を取得するので、directory tree
が途切れていると当然失敗します。
　多分 smbnetfs は、元々 Linux 依存の smbfs の流れを受けてい
るために、library で実装された getcwd(3) の存在なんて想定し
てないんじゃないでしょうかね。


>	utf8-mac 使用時に疑似端末がフリーズする点を修正。

　Mac OS X の UTF-8 は Normalizetion Form を使ってるので、例
えば「か」の後に「゛」が入力されるまで待たないと合字が完成さ
れないんですね。
　PTY 使用時に slave から文字入力があった場合、後続文字を待
ってから次の処理に移るんですが、そこの待ち時間が何と 33.3 時
間になってしまってました。
　本当は 120ms だったんですがマイクロ秒と秒とを取り違えてし
まったために 1,000,000 倍もの大きな差が出来てしまっていまし
た。
　多分 FD-2.09a 辺りでの embug ですが、utf8-mac なんて余り使
わないのでずっとスルー状態でしたね。


> 	起動時のパス名引数が漢字コード変換されない点を修正。

　引数付で起動すると、起動時の CWD を指定出来るんですが、こ
の時に標準の EUC-JP (又は Shift_JIS) 以外の path name を指定
されると、コード変換されずに文字化けしていました。
　と言っても command line から指定出来るコードは限られるんで、
大概は UTF-8 環境でのみ生じていた症状だと思います。


> 	DEFKCODE 指定時のシェル出力文字列の文字化けを修正。

　これが結構悩ましい問題なんですよ。DEFKCODE なんて UTF-8 環
境以外では普通いじらないんですが、逆に UTF-8 環境では本来内
部コードすら UTF-8 にして欲しい訳で、結構綱渡りしてます。
　文字列出力時には、内部コードの EUC-JP から LANGUAGE 指定コ
ードに変換すれば十分だと思っていたんですが、DEFKCODE 指定時
は shell 内部で早い時期に DEFKCODE に変換されてるんですね。
　なので printf.c に %K という変換指定子を追加して、その場合
は DEFKCODE から LANGUAGE に変換して出力するようにしました。

　それでも、%JJ とか使われると shell 入力文字列はどんなコー
ドで記述されているか判断出来ないので、完全という訳にはいかな
いんですよね。
　多分、将来的には内部コードとして UTF-8 を選択出来るように
しておかないといけなくなりそうです。その場合は DEFKCODE の指
定コードが内部コードになるんだと思います。


> 	ShiftJIS 環境での大文字小文字変換ミスを修正。

　Shift_JIS 文字列に何も考えずに tolower(3) や toupper(3) を
適用すると、漢字の 2byte 目まで変換してしまって別の漢字にな
ってしまいます。
　結構あちこちでそういうことやってたんですが、そもそも殆んど
の環境が EUC-JP を内部コードに使ってるので表面化していません
でした。
　勿論 MS-DOS では Shift_JIS なので、dir の結果がおかしくな
ったりしてた筈ですが、MS-DOS 版なんて誰も使ってないというこ
となんでしょうね。


> 	カスタマイザタブ移動時の項目数カウントミスを修正。

　余計な「!」が一つついてただけなのですが、それでは真偽が逆
転してしまうので大きなミスです。
　具体的症状としては、カスタマイザ上で項目の追加や削除を行な
った場合に、一旦他のタブに移動して戻って来ると項目数が増減前
の状態に戻っているというバグでした。
　FD-2.09 での embug のようなので結構古くからの bug でした。


> 	マッピング用キーコード文字列の表記ミスを修正。

　カスタマイザ等でキーコードを「\e[12~」のように表記していま
すが、この文字列生成時に index 変数を increment し忘れてて、
「\e[2」みたいに表示していました。
　FD-3.00g で embug したようです。


> 	ステータス行の日本語ファイル名桁溢れを修正。

　[FDclone-users:00887] で報告のあった bug に対する修正です。


>	アーカイブブラウザ終了時のカーソル位置ミスを修正。

　[FDclone-users:00906] で報告のあった bug に対する修正です。


>	ヒアドキュメント利用時にアーカイブブラウザが失敗する点を修正。

　内蔵 shell を使う popen(3) 相当関数があって、その中で here
document を使うと、親が先に here document 用 temporary file
を削除してしまい、それを使おうとした子側が失敗していました。
　普通は archive browser に here document なんか使いませんが、
組込みコマンド browse を使う場合は、結構便利に here document
を使うんじゃないかと思います。
　しかし browse コマンド自体が使用頻度が低いので、すっかり見
捨てられていました。

　FD-3.00b の変更がトリガとなっていて、[FDclone-users:00804]
にある解説によると、子の終了を待っていると pipe の buffer が
溢れるので、看取らずに次の処理に移るようにしたようです。
　仕方がないので pclose(3) 相当関数の側で temporary file の
削除を行なうようにしました。


>	アーカイブブラウザで不正な改行コードがつく点を修正。(MS-DOS 版)

　MS-DOS は CR LF を改行に使ってるので、archive browser で使
う tar や lha の出力には行末に CR がくっついています。その除
去に失敗した結果、filename に余計な ^M が後続していました。
　これらのコマンド出力は一般的には text なんで、fdopen(3) で
開く時は mode="r" にするのが正しいんですが、FD-2.05b で "rb"
で開くようにする変更が施されていました。
　他の変更箇所に、binary file の fopen(3) で "r" を "rb" に
置換えるという処置が散見されたので、多分勢い余って余計なとこ
ろまで置換えてしまったんだと思います。

　この fdopen(3) を使ってるのは自前の popen(3) 相当関数の中
なんですが、この偽 popen() は archive browser 以外では使われ
ていないので、現状では mode="r" に固定で問題ありません。
　しかし、将来もし他の用途でも使うことになって、その用途では
コマンド出力が binary になるような場合は、mode は "r" に固定
じゃなくて引数で指定出来るようにする必要がありますね。
　元はと言えば、mode="w" の処理が未実装なために、偽 popen(3)
の引数には mode を指定出来ないという仕様が原因だったかも知れ
ません。

　とゆーか、mode="b" なんて仕様は MS-DOS 固有なんで、余り力
を入れて作り込まれていないといったところが実状かも。


>	DJGPP 版で内蔵シェルの端末入力が効かない点を修正。

　MS-DOS 版では DJGPP2 でのみ select(2) が使えるんですが、そ
の対象が端末 (CON) の場合には、select(2) が正しく機能しない
んだそうです。
　具体的には、select(2) と read(2) を繰返して 1 文字ずつ読む
場合、最初の 1 キー分の入力だけ即座に反応し、後続のキー入力
に対しては 1 改行 + 1 キーの入力で初めて反応します。
　info の解説には「DOS が行バッファしてるから」と書かれてい
るんですが、ということは select(2) は DOS 経由ではなく BIOS
を直接見に行ってるということなんでしょうね。

　1 キー目の入力で BIOS 的には「入力あり」になるので 1 を返
しますが、実は DOS 的には行入力が完了していないので read(2)
しても block されます。
　続くキー入力は全て BIOS 側のバッファに溜り、改行の入力によ
りこのバッファの内容が DOS に渡ると、ようやく block が解かれ
て最初の 1 キーが read(2) により読込まれます。
　しかし、次に select(2) を実行した際には既に BIOS 側のバッ
ファは空なので 0 を返し続けます。続く何らかのキー入力により
初めて 1 が返って read(2) に制御が移ります。
　ここから改行までは DOS 側のバッファに溜ってるので、read(2)
は block されずにキー読込みに成功しますし、最後の 1 キーは依
然 BIOS 側に残ってるので select(2) も 1 を返し続けます。
　そうやって改行までは読込まれますが、最後の 1 キーを読込も
うとした時点で DOS 側バッファが空になっているので再び block
されます。これで 1 キー目の入力直後と同じ状態に戻ります。
　後はこの繰返しで、常に「改行 + 1 キー」の入力により初めて
反応するという、ワンテンポ遅れた反応を繰返し続けるという次第
です。

　何も BIOS を使わなくても、DOS 経由でも non-blocking な入力
検知 (AX=4406) はあるんですけどねー。どうしてこっちを使わな
かったんでしょうかね。
　info にあるとおり、read(2) の代わりに BIOS から直接読取れ
ば問題ないので、そのように実装してある UI モードのキー入力に
は特に実害はありません。
　しかし、内蔵 shell で read builtin や here document で端末
入力を用いると、改行に続いてキー入力しないと入力が完結しない
ので、キーが効かなくなったような挙動を示してしまいます。

　仕方がないので、MS-DOS 環境では isatty(3) が真の場合は常に
入力が溜っているものとして扱うようにしました。
　この結果、改行が入力されるまで block されるようになってし
まいますが、DJGPP 以外の MS-DOS 環境では従来からそういう仕様
だったので、この程度は容認して貰いましょう。


>	コマンド履歴ファイルから改行 (^J) を読込めなかった点を修正。

　「echo '12^Jcd'」のように、command line で ^J を用いると、
~/.fd_history には「echo '12^@34'」のように変換されて保存さ
れ、次回読込み時に ^J に戻されます。
　この仕組みが効かなくなっていて、「echo '12」と「34'」の 2
行に分けて読込まれてしまっていました。echo に渡る引数は結局
同じなんですけどね。
　多分 FD-3.00e 辺りで MHpopd とコード統合しようとした際に、
embug したんだと思います。MHpopd には ^@ と ^J の変換なんて
ローカルルールはありませんから。

　そもそも command line に ^J を入力出来る時点で shell とし
ては結構普通じゃないんですけどね。因みに標準の編集モードだと
Ctrl+Q Ctrl+J で入力します。

                                               しらい たかし