ところがどっこいギッチョンチョン(←古いのか、マイナなのかさえ分からん)。 実行している VIO プログラムから、別のプログラムを子プロセスとして呼び出すと、なぁーんと、小アイコンは灰色になるし、SysBar/2 のアイコンは真っ黒になる。要はアイコンを見失ってしまうようなんだな。NYAOS も eff も言うなれば プログラムのランチャーみたいなもんだからこれでは一瞬にして、名無しの権兵衛になってしまふ。
なんか、いい方法ないでしょうかねぇ。見失うってことは、また再認識させてやればいいような気がすんだけど、どうすりゃいいのかな…。あ、また「俺はＰＭ プログラムだっ」と偽の青年の主張を繰り広げればいいのかな…。そのうち、やってみよう。
(((((●〜*
まぁ、それほどうるさなく、結構おもしろいおっちゃんだったから、よかったんだけど、なかなか、あぁいう年代の人に、この手のものの有効さの説明は難しいですねぇ〜。まぁ、先方に理解しようという気がそもそも無さそうだったから、今回は下手な反論はせず、「はいはい、そうですねぇ〜、うんうん」と相づちしか打たなかったんですけどね。
みなさんなら、どう言います？
紙の手帳の方が安くていいぢゃん。
がびーん。(;_;)
ちなみに、ワークパッドで何をしていたかというと、ちゃんと仕事関係のことをまとめていたんですよ！(To Do と残り日数を…あぁ、結構、やば…。某ＹＲＬさん、早く助けて…ディスク直して…)
く、暗いのか…、め、めまいが〜くらくら(バキッ)。うぅむ、Termcap/Curses系プログラムのこと思えば、こんなもんだろうと思っていたのだが、考えが甘かったようだ。これは、さっそくカスタマイズできるようにせねば。
ということで、カスタマイズできるようにしました(あっさり)
ただ、変更できるようにしたと言えども、その辺、色の体系ちゅーんが、変更を前提にしたもんでないので、背景色を全部で統一してないと、ちょっとみっともないことになるかもしれない。また、サンプルに作った _eff (eff の設定ファイル)…、かなり適当なので、各自の好きな色に直すように！元のシックな色調（と思っているのは私だけ？）に戻したい場合は、_eff から color 命令を削除すればよい。あと、残念ながら、_eff の変更を反映するには eff を再起動しなくちゃいけないです。
で、ですな。話はここで終ってなくてですね。これをきっかけに eff に第二の目標が出来たわけですわ。そう、FD系ユーザーを取り込んで、OS/2 の VIO ファイラーの標準的地位を目指すことである。つまり、次はキーバインドカスタマイズだね。今までは、これは実現せねばならぬという機能ばかりが構想にあったもので、他のファイラーを真似る機能は二の次だったのだ。
しかし、時は熟した。立てよ国民(ちがうって)。当初、構想していた機能は基本的に全て実現した！あとは、とっつき易くして、普及させるだけである。ということで、eff はゆくゆくどんとゆく(どこへ？→ 明後日の世界)
(((((●〜*
まず、Oracle。インストーラーまで Java で書くなよ…ったく。RH 6.0 で導入できるものが、RH 6.1 で導入できなくなってしまったら本末転倒だよな。幸い、英語サイト(のかなり奥底)に対策が記述されていたから助かったけど…。日本語ページには、そういうことが全然載ってないもんなー。日本オラクル談「正式対応は RH 6.0 です」。あの、もう、売ってないんですけど…(TurboLinux はハードの都合、使えない。また、ハードの購入元から、OS を伴に購入しなければそこにサポートしてもらえないので、個人的に RH 6.0 をどっかから持ってくるというわけにはいかないのだ、トホホ)
次に、そのRedHat。6.1 の「アップグレードインストール」の、アップグレード元がRH 6.0 だけとは、なんたることですか。RH 5.2 が五橋研究所製といっても、正規代理店だったわけだし…(5.2→6.0 はアップグレード対応してたのかな)。しかも、アップグレードが失敗したせいで、Raid ディスクの一つが見えんようになってしまったではないですか！？(これ実話：まだ直らん)。
自分の事前調査が足りなかったとはいえ…、まったく…。でも、やっぱり、自分が悪いのかしらん…。どうせ、みんな私が悪いのさ、ふん！
ところで、Linux で vi(vim) を SJIS で使う方法はないか、どなたかご存じないですか？いや、データベースの漢字コードを SJIS にしなきゃいかん都合上、漢字コードを ja_JP.sjis にしてるんですわ。でも、これだと TeraTerm から IME を使って漢字を入力できんのです(あたりまえ)。困ったもんです。EUC にしたいのはヤマヤマなんですけどね。
まったく、気ばかり焦る、今日このごろ。愚痴ばっかりですみませんねぇ。
(((((●〜*
たまたま、JFのページのページを読んでいたら、bzip2 の節で、tar に y オプションを追加するパッチが載っていた。で、そのパッチを見ると、量的に少なかったもんだから
こりゃ、ベースの tar が違っても、(手でパッチ)あてられるんでないかい
と思ったもんだ。で、ですねぇ、実際にやろうとしてしまったんだわさぁ〜。用意したものは、AK版 GNU tar 2.58 、そして homy さんの SJIS 用パッチ、んでもって、JFからパクってきたbzip2 パッチだ。途中、バージョンを間違えたりして、いろいろ手間取ったものの、なんとか、homy さん版バイナリと同じものを作ることができた(と思う、多分)。で、次にパッチをあてようとしたわけだ。
ところが、ベースのソースが 0.0.2 の差とはいえども、結構 変わっていたので、やはり、GNU patch は使えそうもない。ということで、文字列"gzip"を検索したり、ごちゃごちゃさわり、結局、vi 片手に改造っぽくやってしまった。
で、どうなったかというと、「tar -y」が「tar --zip=bzip2」と等価にはなったので、一応、でけた！というべきなんだろう。だが、しかし、これで tar.bz2 書庫を作ると、よう分からんが、書庫に後ろに余計なゴミがついてる…(内容は \0 のかたまり)。
1,215 Mar 5 21:59 make_by_pipe.tgz 10,240 Mar 5 22:00 make_by_yopt.tgz 10,240 Mar 5 21:59 make_by_zipopt.tgz 10,240 Mar 5 22:02 make_by_zopt.tgz元々のバグなのか！？ちなみに ytar というのが、葉山のコンパイルしたバージョンです。圧縮・解凍自体は正常に行われるんですけどね。解凍される度に Warning されるし…、これはいったいどういうことなんだろう。
個人的に思うに、OS/2 の tar って、--remove-files オプションが使えないし、タイムタンプ見ると、英語版も 2,3年更新されていないだし、この際、最新の UNIX 版から移植し直した方がいいような気がする…。UNIXからの移植得意な人、誰かやってよ〜(また人に頼る〜)
ところで、上で作った -y 付き tar。結局、問題ありと見て、公開しませんけど、誰か要ります？ 要らんわな、サイズ膨れるんだから…。
(((((●〜*
なんか、別の意味で「ファウンデーションの危機」のような。あ、でも最後まで読まんうちに判断してはいかんな。さっさと読んでしまおう
読み終ったら、前言撤回宣言してたりいて
あ、それ、ありがちだわさ〜。