aklaswad.hatenablog.com

さて何を書こうか

aclii というソフトを書き始めた

取っ散らばったシェルスクリプトと細々したPerlスクリプトと、ときどきnodeと、とにかくどこから手を付けていいかわからんが何とかしないとなんともならない。おしゃれなサブコマンドが実装されているスクリプトの中では [ $1 = "何かしらのサブコマンド" ] || [ $2 = "同じサブコマンド" ] のような地獄が待っている。なんだ今から getoptとか勉強しなきゃいかんのか?別言語にポートするか?Getopt::Longだってまっぴらごめんだぞ?yargsはクール?cobraが強い?彼らは俺を救ってはくれない。今すぐ全人類に叡智を授けてみせろ。

 

そもそも、なにかコマンドラインから作業する時に動いているものは70%くらいはシェルスクリプトだ。

まず入力と実行で50%ずつなのだ。我々はシェルなしでは何もできない。我々の打ち込むコマンドは入力の時点で100%シェルを通過する。そのうえ呼び出し先のかなりの割合で、向こう側もシェルスクリプトだ。

なのに、なんで、実行される言語側の一つずつにクールなパーサーとクールでないパーサーが用意されていていちいちそれらを検証して学習して取捨選択しなくてはいけないのだろうか。

 

俺はそう考え、シェル側にこの問題を寄せて解決してから実行ファイルを呼び出すのが正解だと考えた。

 

aclii は、

  1. 環境に(ほとんど)依存しないPure Bashコマンドライン引数のパーサーを生成するパーサージェネレータです。シンプルな定義をYAMLで書くだけでパーサーとコマンド入力補完スクリプトが生成できます。
  2. 併せて、高機能・・・いや中機能くらいのシェルランチャーを生成します。設定ファイルに書いておけば、好きなサブコマンドで任意のプログラムを実行できるようになります。
    2-1. ランチャーから起動されるプログラムに対して、パース済みの引数をJSONで渡す事ができます。新規ツールを書く際にgetoptなどと対峙する必要がなくなります。
    2-2. 単にexecするだけなので、各サブコマンドの実装は自由に選ぶことができます。
    2-3. YAMLの定義ファイルにインラインで処理を書くこともできます。
    2-4. ヘルプ、マニュアル生成をランチャー側で吸収し、定義ファイルから自動生成します。

というような構想で作り始めた。

 

github.com

aclii - npm