AIが書きがちなシェルスクリプトを、実行する前に確かめる5つの点

シェルスクリプトは短い。5行もあれば、引数を受け取って、フォルダを片づけて、移動して、ビルドまで進む。
読めば分かる気がして、そのまま実行したくなる。

ただ、短いスクリプトは「うまくいく場合」だけを前提にした形になりやすい。引数を付け忘れたら。
名前に空白があったら。cd が失敗したら。
その先で何が起きるかは、行を眺めただけでは見えにくい。

そこで、AIが書きがちな形の5行のスクリプトを1つ用意して、実行する前に見る5つの点を整理した。
空の変数、引用符、cd の失敗、set -eu、shellcheck の5つだ。
rm -rf の行は、すべて echo の後ろに置いて、文字として表示するだけにしてある。

試した環境

使ったのは、shellcheck 0.11.0 と GNU bash 5.2.37。
この環境の /bin/sh は dash だ。
作業はすべて、使い捨てのディレクトリ /tmp/l3 の中で行った。

対象の bad.sh は、引数を DIR に入れ、消す予定の行を表示し、cd して、build と表示するだけのスクリプトだ。

1. 引数が空のとき、何が消えるか

引数を付けずに sh bad.sh と実行すると、DIR は空になる。
rm の行は rm -rf /* になり、ルート直下の項目に展開された。
この環境では25個あった。
表示は rm -rf /bin /boot … と続き、最後に build と出て、終了コードは0だった。

echo を付けていなかったら、と考えると、5行の短さは安心する理由にならない。
最初に見るのは、引数が空のときに rm や cd の対象が何になるかだ。

2. 引用符がないと、名前が割れる

名前に空白があるディレクトリ my dir を渡すと、表示は rm -rf my dir/* になり、cd は「can't cd to my」で失敗した。
それでも build まで進み、終了コードは0だった。

ls でも同じことが起きる。ls -d my dir は、my と dir を別々に探して、エラーを2つ出した。
ls -d "my dir" は、1つの名前として見つけた。変数は "$VAR" と、引用符で囲んで使う。

3. cd が失敗しても、止まらない

存在しない場所 /tmp/l3/no-such-dir を渡すと、cd のエラーが出た。
それなのに、次の行の build まで進んで、終了コードは0だった。

シェルスクリプトは、何も指定しなければ、失敗した行の次へそのまま進む。cd の後ろに消す処理を書いていたら、それがどこで動くのかを考えると落ち着かない。
cd が失敗したときに止まるかどうかを、実行の前に見ておく。

4. 先頭に set -eu、必須の引数は ${1:?}

直した good.sh では、先頭に set -eu を書き、引数を DIR=${1:?usage: good.sh DIR} で受け取るようにした。

引数なしで実行すると、「usage: good.sh DIR」と出て、終了コード2で止まった。
空文字を渡しても同じだった。
存在しない場所を渡すと、cd のエラーのあと build には進まず、やはり終了コード2で止まった。
"my dir" を渡したときは、my dir/a.txt を1つの名前として扱い、build in /tmp/l3/my dir と表示した。

set -e と set -u は、別々にも試した。
set -e がないと、false のあとも次の行の「続いた」が表示された。
set -e を付けると、false で止まって終了コードは1だった。
set -u は変数名のタイプミスに効く。
DIR を DIRR と書き間違えると、何もなければ空のカッコ [] を表示してそのまま進んだ。
set -u を付けると「DIRR: parameter not set」で止まった。

5. shellcheck に読ませる

ここまでの点を、毎回自分の目だけで探すのはつらい。
shellcheck は、シェルスクリプトを実行せずに読んで、書き方の危ない所を指摘してくれる。

bad.sh に使うと、3行目と4行目に指摘が出た。
1つは SC2086 で、引用符で囲め、という指摘だ。
もう1つは SC2164 で、cd が失敗したときに備えろ、という指摘だ。
直し方の候補として cd "$DIR" || exit まで表示され、終了コードは1だった。直した good.sh に使うと、何も出ず、終了コードは0だった。

公式の README によると、Debian 系では apt、macOS では Homebrew、Windows では winget で入れられる。
ブラウザだけで試せる shellcheck.net もある。
この環境では、専用の仮想環境に pip で入れたものを使った。

通っても、まだ残るもの

5つを全部済ませても、安全だと言い切れるわけではない。
試した中で、気をつけたい点が4つあった。

• set -e が効かない場所がある。if の条件で呼んだ関数の中の失敗や、|| の左側の失敗では、スクリプトは最後まで進んだ

• sh と bash は違う。bash の書き方の [[ ]] を sh で実行すると「[[: not found」と出たのに、終了コードは0だった。shellcheck は、sh として書かれたスクリプトの [[ ]] に警告を出した

• パイプの途中の失敗は、set -e だけでは見えない。false | true の終了コードは0で、set -o pipefail を付けると1になった。この環境の sh と bash では同じだったが、ほかの環境の sh は確かめていない

• shellcheck は、意味までは見ない。次の図の blind.sh がその例だ

blind.sh は、引数がないときに対象をルートにする、という書き方をしている。
shellcheck は何も出さず、終了コードは0だった。
実行すると、rm -rf / と表示された。
書き方としては問題がないので、機械は止めなかった。

一方で、rm -rf "$DIR"/* のように、変数が空になると /* に広がる行には、shellcheck が SC2115 の警告を出した。
"${DIR:?}" と書き直すと、警告は消えた。
この確認のスクリプトは rm -rf を含むので、実行はせず、shellcheck に読ませただけだ。

機械が拾うのは書き方、意味は人が読む

shellcheck は、引用符の付け忘れや cd の失敗のような書き方の癖を、きちんと拾ってくれた。
けれど、「引数がないときにルートを消す」が意図どおりかどうかは判断しなかった。
そこは書いた側の考えなので、読む人が決めるしかない。

全部を読み込む必要はないと思う。引数の初期値と、消す対象の行。
この2か所だけは、実行の前に自分の目で読む。

まとめ

• 引数が空のとき、rm や cd の対象が何になるかを見る

• 変数は "$VAR" と、引用符で囲む

• cd が失敗したときに止まるかを見る

• 先頭に set -eu。必須の引数は ${1:?メッセージ}

• shellcheck を通す。通っても、初期値と消す対象は自分の目で読む

どれも、実行する前にできることだ。実行してから気づくより、ずっと安く済む。