"clenv" というシェルスクリプトのモジュール管理ツールを引き続き作っている
上の記事を書いたのが3ヶ月前ですね。
趣味で作っているのでだいぶ波があるのですが、初コミットからは5ヶ月ほど経ちました。
- "clenv" って何?
- "clam" モジュール
- NEW - "cload" コマンドと "cllib" 関数
- NEW - shims/ に shim を置くことにした
- Travis CI で継続的にテストできるようにした
- clenv 環境で使える Bash 用の Logger モジュールを書いてみた
- 今後
- 脚注
"clenv" って何?
https://github.com/key-amb/clenv です。
説明は上の記事に書きましたが、一応こちらでもかんたんに。
私が趣味で作っているツールで、シェルスクリプトの実行ファイルやライブラリをモジュール化して管理できるようにしてくれるものです。
名前はお察しの通り、rbenv など 〜env が由来です。
"version" という語ではなく "environment" という語を使っています。
"version" だと異なるバージョンのシェルをビルドしてインストールして…のようなことを連想されそうだな、と思いまして。
そういうのをできるツールがあってもいいとは思いますが、それをやる気はない。
"clam" モジュール
これも冒頭の記事に書いたのですが、clenv で使うモジュールを "clam" モジュールと呼ぶことにしました。
git の URL か、ローカルのファイルシステムからインストールできます。
モジュール側では clam.spec
というファイルを用意しておく必要があります。
これのファイル形式が v0.3 で少し変わりました*1。
まあ、詳しくは README や脚注の PR をご覧くださいということで。
NEW - "cload" コマンドと "cllib" 関数
v0.2 で導入しました。
.
or source
相当ですが、 CLOAD_PATH
という環境変数の path を見て、そこからの相対パスで読み込めるものです。
これで ruby や perl の require 相当のことができる、と考えました。
面倒なのは、これをシェルの関数で提供しなければならないことです。
スクリプティングにおいては、シェル関数を読み込むコードを一行足すか、 eval
実行する必要があります。
使い方としては、下のようになります。
# 例1 eval $(cload "mylib") eval $(cload "mylib/foo") # 例2 eval $(cload -) cllib "mylib" cllib "mylib/foo"
ここで、 cllib
が "cload" のシェル関数版です。
eval $(cload -)
をやってくれるラッパーコマンドを作ればいいじゃないか、と思う人もいるかもしれませんが、そうすると実行スクリプトを .
または source
して実行せざるを得なくなる気がします。
ので、厳しそう。
NEW - shims/ に shim を置くことにした
v0.2 までは、 shims => environments/$CLENV_ENVIRONMENT/bin
と symlink していただけですが、 rbenv を参考にランチャーとなるシェルスクリプトの実体を置くことにしました。
clam install
するときに、下のようなファイルを実行ファイルと同じ名前で shims/ 以下にコピーしています。
#!/usr/bin/env bash set -euo pipefail [[ ${CLENV_DEBUG:-} ]] && set -x program="${0##*/}" exec "${CLENV_ROOT}/bin/clenv" exec "$program" "$@"
だいたい rbenv や plenv と同様で、clenv exec
で対象のコマンドを探して exec します。
Travis CI で継続的にテストできるようにした
シェルスクリプトでどうやるのかな、と思っていたところ、 b4b4r07/enhancd で Travis が設定されていたので、参考になりました。
実行ファイル系は Bash 前提で書いていますが、シェル関数で機能提供するものは POSIX シェルで動くように書いています。
ので、 make test
タスクもそんな感じで書いています。
いま CI 環境 だと、Ubuntu v12.04 のコンテナで sh
, bash
, dash
で CI が走っています。
あらゆる環境で動作保証するものではないけど、まあ、だいたい動くんじゃないかな、というところ。
※テスト足りてないところは色々あります。
clenv 環境で使える Bash 用の Logger モジュールを書いてみた
https://github.com/key-amb/bash-logger
これです。これ自体は bash スクリプト1枚なので、これだけダウンロードして単独で使うこともできます。
clenv 環境にインストールするには clam https://github.com/key-amb/bash-logger.git
で。
clenv 環境でこれを使うサンプルコードは下のようになります。
# myapp.bash eval $(cload logger.bashrc) log.info "foo" log.warn "warn"
実行すると下のようになります。
% ./myapp.bash 2016-09-19 08:47:35 [INFO] foo 2016-09-19 08:47:35 [WARN] warn
(本当はログレベルに応じて色が変わります。)
まあ、こういうことがやりたいわけです。
つまり、再利用性のあるライブラリを書いて、再利用して楽にスクリプティングしたい。
今後
shims/ 以下は実体を置くことができたのですが、 environments/$env/{bin,lib}
以下がまだインストールした module への symlink になっているので、それも実体にしないと、ライブラリ同士のディレクトリ構成に依存関係があるときに上手く行きません。
解決する方法は2通りあります。
- bin/, lib/ 以下にも中身をコピーする
- uninstall できるように、何をコピーしたか記録しておかなければなりません
- bin/, lib/ 以下に実体は置かない。
cload
時に任意のモジュールについてenvironments/$env/$module/
以下の path を CLOAD_PATH に追加して解決する
前者は clam install/uninstall で頑張る。後者は cload で頑張る感じ。
後者にしても、 bin/ 以下には RubyGems で言うところの binstub 相当を置かないといけないですが、それでも uninstall はだいぶ楽になりそうです。
また、後者にすると同一モジュールでも複数バージョンインストールできるようになったりと、(ニーズはさておき)夢が広がりそうです。
趣味でやっているので、いつになるかわかりませんが、ご興味ありましたら、完成までは気長にお待ちください。
現時点でも上に書いたようなことや、冒頭の記事で書いたような実行ファイルの管理に使えると思います。というか、使っています。
…が、今後、互換性のない変更が入る可能性はありますので、ご注意ください。
脚注
*1:https://github.com/key-amb/clenv/pull/3 https://github.com/key-amb/clenv/pull/4
enhancd を改修して引数なし cd コマンドの挙動を変えずに使えるようにした
先日、上の記事を書きました。
記事末尾に「余談」として、次のように書きました。
もう1つ enhancd による cd の挙動変更でときどき戸惑うのは、 cd 単体で実行したときです。 enhancd ではこのときもディレクトリ履歴検索による選択画面になります。
これはとりあえず諦めて受け入れることにしたのですが、今回紹介した変更のように、デフォルトの挙動を変更しないオプションがあってもいいかもしれません。
すると、意外と反響が有って、ニーズがあることがわかりました。
cd単体でのデフォルト挙動もぜひオプション化してほしい / “enhancd を改修して "cd -" や "cd .." の挙動を変えずに使えるようにした - weblog of key_amb” https://t.co/TWK1yQip4y
— yukimemi (@yukimemi) 2016年9月7日
というわけで、オプションを追加して PR してみました。
で、それが本日、めでたくマージされましたので、お知らせします。
~/.bashrc
などで以下のオプションを指定して、enhancd をご利用くださいませ。
ENHANCD_DISABLE_HOME=1
これで、 cd
コマンドを引数なしで実行したとき、peco などのインタラクティブフィルタを起動せずに、ふつうに $HOME
に cd できます。
Enjoy!
余談
前回の cd -
, cd ..
の拡張の時、ドキュメントの修正までやってなかったので、別 PR でやっておきました。
これも既に master に取り込んでもらっています。
もう一つ余談ですが、enhancd のテストで拙作の shove を使っていただいています。ありがたや。
RSpec で example の外で定義したローカル変数を使うのはアリか?
※9/3 @jnchito さんのコメントを受けて追記しました。
RSpec で example の外で定義したローカル変数を使う
テストコードの例
こういうの:
outside_var = :outside_var # (1) describe :top_scope do top_scope_var = :top_scope_var # (2) it :example_in_top_scope do expect(outside_var).to be_truthy expect(top_scope_var).to be_truthy end context :second_scope do second_scope_var = :second_scope_var # (3) it :example_in_second_scope do expect(outside_var).to be_truthy expect(top_scope_var).to be_truthy expect(second_scope_var).to be_truthy end end end
これまでのところ、他人が書いたコードでこういう書き方を見たことはなかった。
外側で定義した変数を使う場合、 let
を使うか before
ブロックでインスタンス変数に代入するのがふつうだろう。
が、上のような書き方でも、ふつうに期待通りに動く。
特徴・用途
ローカル変数を使う場合には、let
を使って宣言する場合や before
でインスタンス変数を使う場合と比較すると、以下のような特徴がある。
- 変数定義は1回だけ実行される 〜
before :context
相当let
やbefore :each
では、example ごとに実行されるdescribe
ブロックが評価され、RSpec の ExampleGroup が作られる時点で実行されているようだ
- スコープが有効
- 上の例で、
:top_scope
からsecond_scope_var
は見えない let
で宣言する変数やbefore
で定義するインスタンス変数と同様
- 上の例で、
let
同様、typo に気づける。インスタンス変数だとエラーにならないので、気づかない恐れが有る(参考記事を参照)
RSpec の内部構造に踏み込んで深く追ったことはないのだけど、挙動を確認した限り、上のようだった。
ローカル変数のユースケースとしては、一々毎回実行・評価しなくていいような性質のもので、テスト中に状態が変わらないものに使えそうだと考えている。リファクタ用途としても使えそうだ。
「アリ」なのか、「ナシ」なのか?
自分自身としては、何ヶ月か前 fireap *1などを作っていた頃は、RSpec の作法をよく知らなかったので、ローカル変数を多用していた。
しかし、後になって RSpec について色々調べている内に、このような書き方を全く見かけないことに気がついた。
とはいえ、逆に「こういうのは駄目だ」とはっきり書いてある記事やドキュメントもなかった。
…ので、こういう書き方がアリなのかナシなのかというのが、数カ月ぐらい気になっていた。
で、最近初めて自分以外の人でそういう書き方をしている人を見かけたので、気になり度がしきい値を突破して、とある Rubyist が集うチャンネルで聞いてみた。
私「RSpec 詳しい人いますかね? example の外でローカル変数定義して使うのってアリなのかなぁというのが気になってます。こんなの↑(上のようなコード)」
S氏「1. rspec は dsl で書くと、ほらわかりやすいでしょ?というのが走りなので、dsl を使わなくなったらなぜ rspec を使うのか、という話になりそう。
2. let はオプションで thread-safe にしたり thread non-safe にしたり切り替えられるはず。
3. let は それぞれの it の中で、それぞれ呼ばれるのでちょっと動きが違う。
ぱっと思いつくやつ↑」
O氏「
describe "parameterized test" do [ 5, 10, 15 ].each do |i| it { expect(fizzbuzz(i)).to eq("buzz") } end end
みたいなパラメタライズドテストを rspec-parameterized みたいなのをかかなかったら普通にそうなってるので、特に気にしないでやればいいんじゃないかな?」
確かに、そういう書き方をしたこともあった。
ってか、 rspec-parameterized 知らなかった。
2016/9/2 現時点の結論
…というわけで、今のところ自分の中では「アリ」ということになっている。
ただ、テスト実行中に変数の状態が変わったりしたら、なんかまずそうなので、定数にしたり freeze
した方が安全かも、と思ったり思わなかったり。
どうなんでしょうね。
(9/3 追記)
@jnchito さんが、本件についての見解・回答を示すブログを書かれています。
結論だけ書くと「興味深いけど積極的に使うのは NG」という感じです。
興味のある方は是非、上の記事もご覧ください。
9/3 追記:ローカル変数が使えそうな例
なんと、参考記事等でおなじみの @jnchito さんからコメントをいただきました。
正直、Qiita のコメントで聞いてみようかと思ったぐらいなので、僥倖でした。ブログ書いてよかった。
「絶対ローカル変数が良い、というサンプルコードがあれば教えてください」
とのこと。
「絶対」ということはないかな、と思いますが、「まあ、こういうケースならアリかな(?)」と個人的に思う例を3つほど書いておきます。
(1) 長いメソッド等のリファクタ系
特に、実行結果が毎回変わらないものがよさそうです。
describe MyReservationsController do in_sale = Reservation.statuses[:in_sale] reserved = Reservation.statuses[:reserved] cancelled = Reservation.statuses[:cancelled] out_of_sale = Reservation.statuses[:out_of_sale] let(:client) { FactoryGirl.create(:client) } let(:parsed_response_body) { JSON.parse(response.body) } describe '#index' do context '販売中のもの' context 'ログイン前' do it '予約が見つからない' do get :index, status: in_sale, count: 10 expect(parsed_response_body['Reservations']).to be nil end end context 'ログイン後' do before do client.login end it '販売中の予約が取得できる' do get :index, status: in_sale, count: 10 parsed_response_body['Reservations'].each do |r| expect(r['status']) end end end context 'メンテナンス中' do before do expect(MyService).to receive(:maintenance?).and_return(true) end it '予約が見つからない' do get :index, status: in_sale, count: 10 expect(parsed_response_body['Reservations']).to be nil end end end end end
もちろん、 let
で書けないことはないし、↑の例だと get ...
をまとめて subject
化するのもアリと思います。
(2) セットアップに時間のかかるオブジェクトを1回だけ生成し、結果を利用したい
下はプリミティブな DB のコネクション・ハンドラを自作しているような前提です。
conn = MyDatabaseConnector.setup! describe MyTransactionApp do context 'normal' do it do Foo.query(conn, type: :normal) : end end context 'strange' do it do Foo.query(conn, type: :strange) : end end end
RSpec の流儀に合いそうな別解としては、下のように書き換えられることもあるかもしれません:
describe MyTransactionApp do let(:conn) { MyDatabaseConnector.connection } before :all do MyDatabaseConnector.setup! end : end
あるいは、 helper module にできるケースもあるかもしれません。
(3) 時間がかかるわけでもないが、1回だけセットアップして結果を利用したい
target_path = Foo.method_to_get_path(some_arguments, ...) tmp_path = Pathname.new(Dir.tmp_dir) + 'foo' describe MyApp do before :all do # 対象ファイルがあれば退避 if File.readable?(target_path) do FileUtils.move(target_path, tmp_path) end end after :all do # 対象ファイルを復帰 if File.readable?(tmp_path) do FileUtils.move(tmp_path, target_path) end end context 'A' do before do File.write(target_path, 'A') end after do FileUtils.remove(target_path) end it 'target_path の内容に依存するテスト' do : end end context 'B' do before do File.write(target_path, 'B') end after do FileUtils.remove(target_path) end it 'target_path の内容に依存するテスト' do : end end end
この場合の別解としては、 target_path を helper method にしたり、 tmp_path をインスタンス変数にして before :all でセットする、というやり方もできそうです。
参考
enhancd を改修して "cd -" や "cd .." の挙動を変えずに使えるようにした
Bash で enhancd を導入することにした
cd の履歴を peco で移動したい。
シェル環境で peco を使いだした人なら、きっとそう思うことがあるでしょう。
zsh だと、cdr と組み合わせることで実現できます*1。
下の記事あたりを参考に設定するといいでしょう。
さて、bash の場合、最近は b4b4r07/enhancd を使う人が多いのではないかなと思います。
いくつか作者の @b4b4r07 さんが記事を書いてます。
この enhancd は Bash の小枝集 で紹介されている cdhist.sh
をベースに作られたそうです。zsh と fish にも対応しているそうです。
自分も一瞬、何か自作しようかと思ったのですが、enhancd が便利そうだったので、まずは使ってみることにしました。
使い方は README の通りですが、ソースを clone して . init.sh
するだけです。
これで cd
が enhancd の関数に alias されます。
色々機能がありますが、詳しくは上に挙げた Qiita の記事がわかりやすいだろうと思います。
とりあえず、自分にとって最低限必要だったのは cd -
で cd の履歴を検索して移動できるようになることだけでした。
他に、 cd ..
すると peco が起動してディレクトリを上方検索してくれました。
Pull Request に至る経緯と改修後の enhancd の設定方法
最初「おぉ。これは便利」と思って使っていたのですが、しばらく経ってから cd -
や cd ..
を打つと、以前の挙動と違って peco の選択画面になるので、戸惑うことに気づきました。
慣れようと思ったこともありましたが、無理でした。
元々、それ以前に peco を使う機能にはキーボード・ショートカットを割り当てることにしていた*2ので、そちらに寄せたいと思いました。
また、以前は運用エンジニアとして色んなサーバに出入りしていたこともあって、あまりデフォルトの挙動を変えたくないという気持ちもありました。
というわけで、 cd -
や cd ..
のデフォルトの挙動を変えずに、ディレクトリの履歴検索や上方検索を別の特別な引数に割り当てられるようにする Pull Request を送りました。
この PR を送ったのは2ヶ月ほど前のことでしたが、一昨日ようやくマージしてもらえました。
~/.bashrc の設定例は次のようになります。
ENHANCD_HYPHEN_ARG="-ls" ENHANCD_DOT_ARG="-up" . path/to/enhancd/init.sh bind -x '"\C-ur": cd -ls'
ENHANCD_HYPHEN_ARG
と ENHANCD_DOT_ARG
が追加した設定用の変数です。
上のように設定すると、 cd -ls
でディレクトリの履歴検索、 cd -up
で上方検索が可能になります。
また、 cd -
, cd ..
がデフォルトの挙動($OLDPWD
, ..
への移動)に戻ります。
キーボード・ショートカットとしては履歴検索に Ctrl-u + r
を割り当てました。
cd -up
には割り当てていませんが、覚えていれば問題ないです。たまに便利。
結びに
bash 環境に enhancd を導入し、 cd -
, cd ..
の挙動を変えずに使える機能拡張をしました。
enhancd をご利用の方や、これから利用される方の参考となれば幸いです。
余談
もう1つ enhancd による cd の挙動変更でときどき戸惑うのは、 cd
単体で実行したときです。
enhancd ではこのときもディレクトリ履歴検索による選択画面になります。
これはとりあえず諦めて受け入れることにしたのですが、今回紹介した変更のように、デフォルトの挙動を変更しないオプションがあってもいいかもしれません。
※追記:こちらについてもパッチを送って、デフォルトの挙動を変更しないオプションをサポートしてもらいました。
参考
See Also
脚注
Bash Infinity よりずっと前に Bash on Rails なるものを作った人がいると記録しておく
備忘録を兼ねて、ブログを書いておきます。
きっかけは、昨日のはてブでホットエントリに上がっていた下の記事です。
元記事から、GitHub のソースコードにたどりついて、少しだけ内部のコードを読みました。
https://github.com/niieani/bash-oo-framework
どうも、Pure Bash で書かれているようですね。
OO という名前が現すように、オブジェクト指向で書けるように型システムをも実装しているようです。と、これは記事でも紹介されていましたが。
さて、この記事を読む数カ月前に、私は Bash on Rails なるものを作っていた人を知ったので、それを想起しました。
Bash on Rails は @emasaka さんが作った Rails モドキで、「Bash の機能だけでいかに Ruby on Rails っぽいことができるか」を実践したパロディ企画とのことです。
作者のブログ でのべ14記事にわたって紹介されています。
関係する記事の一覧は、下記の検索結果からが見やすいです。
http://emasaka.blog65.fc2.com/blog-entry-379.html?q=bash+on+rails
Bash Infinity 同様、Pure Bash かつ OO で書かれており、Rails の scaffold や db:migrate を模した機能もあります。
他に、ERB を模した eBash が実装されてたり、model や controller があったりと、まるで Ruby on Rails です。
ジョークソフトにしては力が入りすぎているような気さえします(笑)
(※もちろん、本家 Rails に有って Bash on Rails にない機能はたくさんあるでしょうけど)
ブログ記事の中で、コアの部分で面白そうな記事を1つだけ挙げるとしたら、本を読む Bash on Railsを作る(10) bashOOをbashOOで作る を推します。
オブジェクト指向をどうやって実現しているか、コードを混じえて紹介されています。
この記事だけでも一見の価値はあるかな、と。
GitHub 上では shails という名前でソースコードが公開されています。
https://github.com/emasaka/shails
Bash on Rails を初めて見つけたときは、「Bash ってここまでできるのか」と感動したものです。
そこまでやる必要があるのかはさておき。
ご興味がある方は、ソースコードや記事を読んでいただくと面白いと思います。
Bash on Rails と Bash Infinity の「実用性」について
Bash on Rails はそもそもジョークプロダクトで、まともな用途で使わないでね、とブログで書かれています。
こちらも内部のコードを少し追いましたが、eval など駆使して無理やりオブジェクト指向っぽく見せているような感はありました。
あくまでオブジェクト指向を「模している」だけなので、違うものだという前提を持った方がいいでしょう。
Bash Infinity は実用的なプロダクトを目指しているのかな? と思わせる雰囲気で、 GitHub 上でかなりスターもついてます。(昨日は1000弱でしたが、さっき見たら1000を超えていました。)
…が、どのくらい実用的なのかは疑問符です。テストライブラリは付属しているそうですが、Bash Infinity 自体のテストコードが見当たらないような…。。
最初に挙げた記事に書かれていたように、「各ライブラリでどのようなテクニックが使われているか」の勉強にはよさそうだな、と思いました。
余談
@emasaka さんのブログをあさっていたら、sinatra モドキも作っていたことを知りました(笑)
以下は、記事から引用:
「…"sh inatra"って言いたかっただけと違うか?」と思ったあなた、はい、そのとおりです。