卜部昌平のあまりreblogしないtumblr

■ #!/usr/bin/env

_ 今さらながら、 CGIの神話と現実というエントリ。ただし内容とはまったく関係なし。スクリプト言語の shebang 行（#!）でスクリプトインタープリタを直接書かずに /usr/bin/env でラップするという悪習はいったい誰が広めたんだろうか。ruby な人に多いように思うがそれだけじゃないし。

_ hoge というインタープリタを使うスクリプトの1行目をたとえば #!/usr/bin/env hoge としておくと、hoge の実行バイナリが /usr/bin/hoge でも /usr/local/bin/hoge でも $HOME/bin/hoge でもどこにあってもパスが通ってさえいれば起動できる。それはメリットなんだろうか。わしにはむしろデメリットにしか思えない。

_ /usr/bin/env を使うというのは、PATH の値にしたがってインタプリタの場所を探すという意味である。つまり、スクリプトを書いた人と実行する人で設定が違えば同じインタープリタが起動するとは限らない。OS 標準の /usr/bin/perl と、そのホストで独自にコンパイルした /usr/local/bin/perl と、ユーザが自分用にコンパイルした $HOME/bin/perl とが存在している場合、#!/usr/bin/env perl となっていてはどの perl が使われるのかわからないし、もしかしたらそもそもインタープリタを見つけられないかもしれない。どこにインストールされているかに依存せずに実行できる、というけれど、$PATH という別のものに依存するようになっただけだ。異なるバージョンのものを複数インストールしてある環境は珍しくないと思うのだが、同じ名前でも同じ動作をするとは限らない（同じ動作をするのならいくつもインストールする意味がない）わけで、インタープリタの位置を明示しない記法というのは害になっても益になることはないと思うのだが。

_ OS によっては env が /usr/bin ではなく /bin に存在するものもあるらしい（MacOSX 10.1 がそうらしい）。env 自身が環境依存という時点で、環境依存性の回避というのは幻想に過ぎないと斬って捨ててもいいと思うんだが、仮に幻想のまま /usr/bin/env を前提にできるとして、それでもなお意図しない動作をしてしまう例を挙げてみる。

_ たとえば FreeBSD では、標準の /etc/crontab は

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin

となっていて /usr/local/bin が含まれていない。なので、

#!/usr/bin/env ruby

というスクリプトを /etc/crontab に登録すると、FreeBSD では ruby は /usr/local/bin にあるのが標準なので、インタープリタを見つけられずにエラーになる。

_ Apache は起動時に環境変数をクリアしない。なので、OS 起動時に自動で起動される場合と、PATH=$HOME/bin:/usr/local/bin/usr/bin:/bin な環境で sudo apachectl start する場合では PATH の値が異なることがある。CGI にわたされる PATH は Apache 起動時の PATH がそのまま使われるから、つまり、/usr/bin/env でラップしている CGI では、Apache がどのように起動されたかによって異なるインタープリタが使われる（あるいはインタープリタを見つけられない）ことがある。

_ こういう問題は cron や apache にかぎらず、シェルのコマンドラインからではなくデーモン類から起動されるもの全般で発生する。たとえばメールの自動処理をするために aliases や .forward、.qmail、.procmailrc などからスクリプトを起動する場合にも、MDA がスクリプトにわたす PATH の値によって同じような問題が起きるだろう。

_ そもそも、

#!/path/to/cmd a b c

のように複数の引数を shebang 行に書いた場合、/path/to/cmd にどんな引数が渡されるのかは OS によって異なる。”a b c” というひとつの引数が渡されるもの（Linux とか FreeBSD >=6 とか）、”a” “b” “c” という3つの引数が渡されるもの（FreeBSD <=5 とか）、”a” だけが渡されるもの（Solaris とか）、さまざまである（ 参考）。つまり、

#!/usr/bin/perl -Tw

ならば、引数がひとつだけなのでどんな環境でも書いたとおりに /usr/bin/perl -Tw が実行されるが、 ここにあるように

#!/usr/bin/env perl -Tw

とするとそうはいかない。FreeBSD 5.x では意図どおり動くが、Solaris では -Tw が無視され ^(*1)、Linux では “perl -Tw” なんてコマンドはないというエラーになる。perl がどこのパスにあっても起動できるよう環境非依存にするつもりで /usr/bin/env を使ったのだろうが、逆に /usr/bin/env を使ったが故に環境依存の罠にハマっていることになる。これはまた、#!/usr/bin/awk -f や #!/usr/bin/sed -f のように shebang 行で引数が必須の言語は多くの環境で #!/usr/bin/env awk -f のように代替できないことを意味する。

_ それでも #!/usr/bin/env の方がすぐれているという方、反論求む。

---

(*1): ただし、OS レベルでは無視されるが、perl 自身がスクリプトに書かれた shebang 行を解釈するので、perl として起動された後で perl -Tw として起動されたかのように動作を変更しようとする（その結果エラーになる）。っていうか、perl hoge.rb とか perl hoge.sh とかでも、shebang 行さえ書いてあれば ruby なり sh なりにスイッチしてちゃんと動いてしまう。ruby も perl と同じように shebang を解釈するが、あらゆるスクリプト言語が同じように shebang 行を解釈してくれると思ったら間違いである。