Lua のインスタンスのクローンについては今のところ問題は出ていない。 無論、不具合の一つ二つは出たが、 確認当日中にあっさりと解決できて、この程度で済むのなら上出来だったと思う。
また、もう一つの懸案も解決できた。
これは Args[] を Windows 風の一枚引数文字列に展開する際の二重引用符の扱い方のために、 FIND コマンドが期待するような「検索文字列の前後には二重引用符をつける」という仕様を呼び出し時に満たすことができないという問題だ。
この issue 自体は最近起案したものだけれども、Args[] の展開を自前でやるというのは前々からの課題だった。
やろうと思うと、API の CreateProcessW を呼ぶライブラリから作られなばならないと思っていたので、
すぐには実現できないと思っていた。
が、Go のライブラリのソースを見てたら、実は Args[] の展開を自分でやる手段が提供されていることが分かり、
思わぬタイミングで懸案は解決した。
詳細は前に書いた記事を参照のこと。
というわけで、結構大きい課題が二つの解決して、満を持して 4.2.0 をリリースしたいところだが、もう一つ欲張りたいところがある。
それは foreach とか if ～ then ～ endif とかの制御構文。 nyaos-3000 は、その辺をちゃんと実装していたが、nyagos は Lua で全部やればいいからと完全にスルーしてしまった。 ところがユーザの傾向を見ると、Lua だからカスタマイズの仕方が分からない、調べれば分かるが、学習コストに見合わないという人が多い。 完全に計算違いだった。
foreach を実装するには、コマンド列の任意の位置へ移動できなくてはいけない。 そのためには shell パッケージは単品のコマンドの実行だけではなく、前後のコマンドも含めたセッションも管理して、 コマンド列の移動可能箇所をマーク＆移動できるようにしなければいけない。 これまでは一連のコマンド列の管理は mains パッケージ（旧mainパッケージ）で行っていた。 昨日・今日で、それをようやく shell パッケージ（旧interpreterパッケージ)側に移動した。 結果、mains パッケージからは「shell.Loop(コマンド列読み込みオブジェクト)」だけを呼ぶだけとなった。
これ、日本語で書くと簡単に見えるが
- shell パッケージは Lua へ依存させてはいけない。Lua への依存は mains パッケージが隠蔽するか、注入するかしてやらないといけない
- インタラクティブシェルか、スクリプトかの管理に shell パッケージは関与してはならない
とか制約が多くてたいへんだった。が、最終的にはコマンド列読み込みインターフェイス
package shell
type Stream interface {
ReadLine(context.Context) (context.Context, string, error)
GetPos() int
SetPos(int) error
}
をベースにうまいこと実装できた。おかげで shell パッケージは奇麗さを維持できた。 が、mains パッケージはかなりグダグダである。 「依存性」が全部 mains パッケージに集まってるのだから仕方がない。
