こんにちは、川合です。
今回はコマンドラインに関する概念的なことを書きます。
CUIといえば、標準入力と標準出力と標準エラー出力があり、そして
標準入力と標準出力とを上手につないで利用するタイプのアプリケーシ
ョンをフィルタと称して重宝するイメージが、僕にはあります。
いきなりですが、OSASKには標準入力や標準出力はありません。・・
・「ない」と言ってしまうと語弊がありそうです。入力と出力はありま
す。ただ、どれが標準とかそういうのがあるわけではない、ということ
です。
一つのストリームから入力して、一つのストリームを出力するという
モデルが一般的なフィルタですが、OSASKでは複数のストリームから入
力し、複数のストリームへ出力するのです。また、ストリームという語
もふさわしくないといえます（ストリームはシーケンシャルアクセスの
イメージがあります）。[OSASK 4273]に書きましたとおり、パイプであ
ってもランダムアクセスできるというのがOSASKです。ファイルももち
ろんランダムアクセスです。
入力も出力も1つというモデルでは、データの流れが一直線でした。
流れが分岐するような場合では、一度ファイルに落としてそれを2度処
理にかけるといったようなことが必要でした。OSASKではそういう制約
はなくなります。パイプを縦横無尽につないで、不必要な中間ファイル
を生成することなく、目的のものをリアルタイムに得られます。
例を出しましょう。たとえば、家にテレビとビデオデッキとスピーカ
があったとします。ビデオの画像をテレビに送って音声をスピーカに送
りたいとします。この場合、ビデオが画像出力端子と音声出力端子を別
々にもつからこそ、そういう配線が可能なのです。一般的なCUIシェル
では、このような「配線」はできません。ビデオの出力オプションで音
声のみを抽出したファイルを前もって作っておいて、それをバックグラ
ウンドでスピーカに送りつつ、画像をテレビに送るわけです。これは端
子が一つしかなく、どちらか一方しかパイプとして出力できないからで
す。これは不自然です。
スピーカへ出力する前にサラウンドエフェクトフィルタをかけたり、
他の出力機器からの音楽とミックスしてからスピーカに送ったりしたい
こともあるでしょう。画像の方もエフェクトをかけてノイズを減らして
もいいですし、他の画像ソースと併せて重ねたり、画面分割をして一つ
の画像にまとめたりすることもあるでしょう。
こういうことをやるには、どうしても複数の入力や複数の出力が必要
なのです。そしてOSASKのアプリは、このようなパーツ化されて入力端
子や出力端子を複数もつ存在として振る舞います。より厳密には、これ
らの機器に相当するのはタスクです。アプリはタスクを生成するための
仕組みです。C++でいうことろの、オブジェクトとクラスの関係です。
OSASKのタスクはご存知の通り、タスクセーブができます。また、任
意の時点でリダイレクト先を変更することもできます。CDからカセット
テープにダビングしていて、テープを録音状態のまま一時停止して、他
につなぎかえて録音を再開するようなイメージです。必要でしたら、も
ちろん一時停止しないで切り替えてもいいですが。
さて、このような機能を実現するのに必要なCUIはどんなものかとい
うと、実は僕にもよくわかりません。文法をある程度拡張しなければい
けないというのは、確実です。
CUIではなく、GUIだったら話はそれほど難しくありません。「プロセ
ス生成」というアイコンをクリックすると、広いスペースが表示されま
す。その何もない空間へ、タスクというオブジェクトを自由に並べます
。また各タスクには「端子」があって、これをマウスを使ってラインで
結んでいきます。もちろん、タスクが多くなってごちゃごちゃしてきた
ら、タスクをドラッグして移動させたりします。この時もちろん端子に
結ばれたラインもついてきます。
これらのラインは家電でいうところの配線コードに相当します。タス
クは家電です。そしてこれらを配置している空間は部屋です。・・・一
通りの配線ができたら、プロセススタートボタンを押します。これで全
てのタスクがいっせいに起動し、組み上げた配線通り、データがやり取
りされ、望みの出力がリアルタイムに得られます。
プロセスという語は、とりあえず、タスク群という意味合いで使って
います。もしもっとふさわしい言い方がありましたら、ご提案ください
。
なお、こうして作ったプロセスの一部の配線をしないでおいて、全て
の機器を一つの箱につめて、配線していない端子の部分だけを外部に出
しておいたらどうなるでしょうか？そう、これは新しい複合機器の完成
です。「入力音声をFFTで分解して特定の周波数帯だけを抽出して再度
波形に戻して出力する」というフィルタを作ることもできるでしょう。
そしてこれもあたかも一つのタスクとして利用できるというのが僕の理
想です。つまり、バッチファイルをアプリケーションと同格にしている
だけなんですが。
逆に、複雑なアプリケーションも内部はサブアプリケーションの集合
でしかなかったという事がありえます。GUIでメールを読み書きするア
プリも、中身はカスタマイズ性の高いテキストエディタと、必要に応じ
てリダイレクトを制御するメニューアプリと、指定されたテキストをメ
ールとして送信・受信するプログラムと、簡易ファイラで構成されてい
るかもしれません。もしこれらを個別にコントロールできれば、より自
由に多くのことができるようになるかもしれません。これは、コンポが
ユニット式になっていれば、自由に組み合わせられるというのに似てい
ます。まるで自作AT互換機を作るように、アプリケーションを組み立て
たりばらしたりして、利用できるようにしたいです。
---
さて本題のコマンドライン文法です。
複数の入力や出力がある以上、それらを区別できなければいけません
。また入力か出力かとはっきり区別できないかもしれません。とにかく
一般的には、
入力系 ： in, in0, in1, in2, in3, in4, ..., in9
出力系 ： out, out0, out1, ..., out9
区別しないもの ： file, file0, file1, ..., file9
その他 ： 上記以外の全て
と名前をつけます。これは端子の名前（ラベル）です。「画像入力1」
みたいなものです。もし先のGUIによるプロセス生成画面では、マウス
カーソルが端子に触れれば、端子名としてこれらの名前が表示されるで
しょう。また端子名は複数の表記が可能です。つまり、inとin0とvinと
video_inは全て同じものを表わす、なんてことが可能です。GUIの場合
にどれを端子名として表示させるかは、決めておかなくてはいけません
が。
そして、これらを使って、
prompt> prog in:abc.txt out:def.txt
などとやるわけです。そしてみなさんは気が付きます。おお、これはob
j2bimやbim2binの文法ではないかと。そう、そういうことだったのです
。
なお、デフォルト順序というものもありまして、
prompt> prog abc.txt def.txt
という簡略表記も可能です。これはつまり、1つ目のものはinに、2つ目
のものはoutにと決めてあるからです。アプリケーションごとにこのよ
うなルールが決まっており、だから他のアプリでは1つ目のものがoutで
2つ目のものがout1で、3つ目のものはinだ、ということもありえます。
また記号"<"はinへの接続を、">"はoutへの接続を、">>"については
outにパイプをくっつけて、その先にappendorというタスクをくっつけ
て、こいつがくっつけるための処理をする、という風に処理します。
残るはオプションパラメータです。これは全てラベルとして定義して
おきます。"-osacmp"とか、"-tek0"などというラベルがあるわけです。
ラベルの後にコロンを打って文字列を与えることもできます。stack:4k
とか。
細かいルールはこれから決めますし、それをアプリがどうやって参照
するのかもこれから決めますが、とにかく、全体的な戦略は以上の通り
です。補足すると、シェルがコマンドライン文法の解釈に手をつけてい
るので、アプリはコマンドラインパラメータの解釈のチェックを簡略化
できます。つまり、stackがstockと間違って入力されていないかとか、
そういうチェックはしないでいいわけです。それは「対応するラベルが
ない」というエラーになって、アプリが起動する前にエラーではねられ
ますから。
また複雑なプロセス生成をCUIで実現することについては、多分バッ
チファイルの文法を拡張することで対応することになると思います。ま
あバッチファイル無しでもできるようにすると思いますが、間違えた場
合の訂正の手間を考えると、バッチファイルでの利用がメインになると
思います。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/