[FDclone-users:00380] Re: 日本語文字コード(UTF8) 環境での動作について

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20050413163243.25680806.32235@nifty.ne.jp>
        =?ISO-2022-JP?B?GyRCSXBEZyEhMGw7MBsoQg==?= <HCD02054@nifty.ne.jp>さんwrites:
> 　このへん、ユーザーの使い方も勿論なんですが、アプリケーション側が独自に対応し
> ちゃってる現状がある意味それを現してるんだと思います。

　んー、やっぱ背景文化としての UNIX は DIY が基本なので、ア
プリ作者による一方的な実装の押付けという土壌は育って来なかっ
たんだと思いますが、どういうニーズが一般的なのかがもう少し明
確になってくれば相乗効果が得られて来ると思うんですね。
　こと free software 業界に関しては思いの他エンドユーザから
のニーズって上がって来ないようで、アプリに機能追加するきっか
けが作者の独善に過ぎないなんてことも少なくない訳で。
　作る方は技術的興味が先に立つことが多いので、その応用に当た
る現場でのニーズが一体どのようなものなのか見極めた上で実装す
るよう、私は心がけてるつもりなんですが。

　pty の実装は実用的なメリットも大きいと個人的には思ってるん
ですが、これも独善かも知れません。


> 　もう一つ言えるのは機能や単語だけでは、必ずしも直接的なイメージに結びつかない
> 人の方が多いんでは無いかと。

　end user は技術知識の基盤を持ってないことが多いので、その
新機能の実装により何がどう幸せになれるのかピンと来ないんでし
ょうかね。


> 　さらに、無いのが当たり前になってると、当然その新機能が使われる場面自体ナチュ
> ラルに回避するのが当たり前になってる訳で。

　んー、この姿勢は初心者だろうがベテランだろうが余り誉められ
たものではないんじゃないかと思います。
　自然法則のようにどうしようもない事象とは異なり、コンピュー
タ上の事象はある程度思い通りに操作出来る筈で、そういうことに
思いを馳せずに現状に甘んじるというのは多分に後向きかと。
　「こういうもんだ」と言われて「はいそうですか」と返し続ける
だけでは、何も新しいものは生まれて来ません。これは別にソフト
に限った話ではなくて人生哲学的な話にまで発展し得ると思います。

　私はむしろこういう「当たり前」に対する接し方としては、下手
に知識を持ってる上級者よりは、bias のかからない純粋な目で見
ることの出来る初心者の方が長けていると思っています。
　だから、無いのが当たり前だからニーズが無いってのはちょっと
悲しいかな。現状に甘んじることなく、欲しいと思ったらもう少し
足掻いてみてもいいんじゃないでしょうか。


> 　そう言う意味では、 FD に於けるコマンドラインってのは、あくまでも lanucher に
> 渡す引数を補うための存在だと割り切るべきなのかもしれませんね。

　command line でなくても pty は使い道ありますよ。従来の枠組
では同時に複数の file 閲覧は出来ませんでしたが、画面分割状態
で pty 使えば上下でそれぞれ独立して閲覧出来ますし。
　むしろ command line を含む shell としての一面からは pty は
余り嬉しくはないかも知れません。pty のために子を作ってしまう
と builtin なのに別 process なんてことも出て来ちゃうし。
　今実験的に作ってる実装でも、command line から環境変数の設
定を行なっても FDclone 自身に反映されなくて悩んでますし。

＃　真面目に実装するなら exec() する時にだけ pty を使って、
＃builtin は pty を使わずにそれっぽい動作を実現させるべきで
＃しょうね。
＃　ただ、exec() に至るまで pty をお預けにしておくと pipe や
＃redirect が処理しづらいんですよね。setsid() の無い OS だと
＃全部の file を close() しないと制御端末を切り離せなくて、
＃もしそれをすると redirect された file descriptor までいな
＃くなっちゃう訳で。


> 　でも、そうなると FD 内部で取り扱うために文字コードが変換されるってのも、本末
> 転倒になりかねないのかな(^^;)。

　んー、この話は Samba の開発陣でも何度か話題に上ってるんで
すけど、やはりユーザから見ると不必要な変換であっても、それに
よって処理に一元化が図れるので無駄な実装が減るんですよね。
　10 個の漢字コードに対応するために 10 種類の処理ルーチンを
用意するなんてのはナンセンスで、ここは 10 個の convertor と
1 個の処理ルーチンで対処すべきでしょう。

　勿論それを user に見せちゃあいけないんですけどね。

                                               しらい たかし