What is shebang (#!/bin/sh) in POSIX shell script

コマンドが実行できない場合

1.の場合は，単純なテキストファイルに実行権限が付いた場合が該当する。この場合，execl()はインタープリターとしてshコマンドを使って，まるで以下の形式で実行した環境かのようにexeclp()とexecvp()を実行する。

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

ここで，<shell path>はshの絶対パス，fileはプロセスのイメージファイル（ファイル名？）arg0，arg1は引数となる（arg0はfileと同じ？）。

つまり，実行可能なバイナリーファイル以外はすべてshによるシェルスクリプトとみなされる。

この仕様のため，シェルスクリプトの1行目にはshebang（#!/bin/sh）がなくても，shで起動される。試しに以下の内容のhi.shというスクリプトを作って実行すると，shebangがなくてもshによって実行されていることがわかる。

ps -p $$ -o comm=
ps -p $$ -p args=

sh
/bin/sh ./hi.sh

Shebang（#!）がある場合

2.の場合は，一般的なシェルスクリプトのパターンだ。これは，ファイルの先頭2バイトが#!であれば，ファイル1行目の#!以降の残りの文字を実行するコマンドインタープリターとみなす。

つまり，以下のようなシェルスクリプトでは，#!以降で指定される/bin/shによりファイルが実行される。

#!/bin/sh
ps -p $$ -o comm=
ps -p $$ -p args=

ファイルの先頭2バイトをチェックしているので，UTF-8やUTF-16などでBOM（Byte Order Mark）が付いている場合，shebangは認識されず1.のルートでスクリプトが実行される。その場合，BOMがコマンドとみなされて，当然ながらそんなコマンドはないので，line 1: command not foundというエラーが出る。

一応，以下のようにエラー出力を捨てるコードを1行目に書けば，BOMありでも実行できるシェルスクリプトは作れる。しかし，こんなことをするくらいなら最初からBOMなしで書いたほうがよいだろう。

: 2>-

Shebangによりシェルスクリプトを実行する際に，一つだけ問題がある。それは，以下で記載されている通り，sh側で#!から始まるファイルを読み込んだときの挙動が不定なことだ。

つまり，大昔のOSなどでは#!/usr/bin/perlから始まるファイルをshで起動した場合，/usr/bin/perlが起動することもありえる。

そのため，真の意味で可搬性が高いといえるのは，shebangを書かない1.の方法だ。ただ，shebangは広く普及しており，現在の実装では#!から始まるファイルをshが読み込んでも，その行は単にコメントとして無視される場合がほとんどだ。また，POSIXのshコマンドのページにおいても，shebang #!が書かれたシェルスクリプトを意識した記述もある。

このことから，わかりやすさと実状を考慮して，shebang行に#!/bin/shを書いても問題ないだろう。

Shebangに指定するパス

まずは，shebang行に何を書けばよいかという議論だ。一般的に，シェルスクリプトでは以下のように/bin/shで指定することが多い。

#!/bin/sh

ここで，はたして本当に/bin/shと書いて問題ないのだろうか？実のところ，POSIXでは/binというディレクトリは定義されていない。

さらに，POSIX規格ではshが/bin/shまたは/usr/bin/shにあるとせずに，自分でgetconf PATHコマンドでPATHを取得するように書かれている。

ただ，このようになってしまうと結局shebangの指定に互換性がなくなり，環境ごとにshebangの書き換えが必須となってしまう。

ではどう考えるか。これはFilesystem Hierarchy Standard (FHS)への準拠を考える。FHSはLinuxを含むUNIX形OSでの主なディレクトリとその内容を定めたものである。したがって，FHSで定義されているコマンドのパスは前提としてよいと考える。

FHSで存在することが必須とされているコマンドは/bin配下のものが大半であり，残りの/usr/bin配下などに含むコマンドはほとんどオプションだ。/bin配下に存在することが要求されているコマンドは以下の35コマンドだ。

cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname, test, [

3.4. /bin : Essential user command binaries (for use by all users) Filesystem Hierarchy Standard

この中に，shコマンドが存在している。したがって，FHSに準拠しているOSでは/bin/shは存在することが保証されているので，shebangとして#!/bin/shと書いても問題ない。

ここで注意したいのはFHSではbashやcsh，envコマンドの存在は必須ではなかったり，定義されていないことだ。したがって，#!/bin/bashや#!/usr/bin/envから始まるスクリプトは可搬性が低い。実際のところ，/bin/bashは存在することが多いのだが保証はできない。

/usr/bin/envが定義されていないというのは重要だろう。というのも，シェルスクリプト以外のスクリプト言語（Perl，Python，Ruby）では，#!/usr/bin/env pythonのようにenvコマンドを経由して実行させるshebang行がよく書かれるからだ。

スクリプト言語のインタープリターはPOSIX規格でも定義されておらず，どこにインストールされているかは全く不明だ。一応，FHSでは/usr/binにperlとpythonが存在することがオプションで定義されているのだが，あくまでオプションだ。それに，これらのコマンドではシステムにインストールされたものではバージョンが古いため，ユーザーが独自にインストールしたものを優先して使いたい場合がある。

そこで，envコマンドを経由してユーザーのPATHを使うことで，インストール場所の問題を回避することがよくなされる。FHSでは/binはシステム管理者とユーザーの両方に使われるコマンドが含まれる。envコマンドはシステム管理者には不要なので，/usr/binにenvコマンドが存在することが多い。

大半の場合/usr/bin/envは存在するが，存在しない実装もある。そこで，確実に実行させるために/bin/shを経由してスクリプト言語のインタープリターを実行する方法がある。

• Perl, Python 及び Ruby スクリプトにおける正しいshebangの書き方 – Qiita
• あなたの知らないShebang | κeenのHappy Hacκing Blog

シェルスクリプトのコメントと，スクリプト言語のコメント文字が違うことを利用して，スクリプト言語のコメント内にシェルスクリプトでexecコマンドを記述して，スクリプト言語のインタープリターを起動するというトリックを使っている。

個人的にはそこまでする必要はないと考える。PerlもPythonもRubyもPOSIXに存在しないし，そもそもインストールされていなくてPATH変数に存在しないかもしれない。あまり気にしなくてもいいのではないか？

基本的には，#!/usr/bin/envで記述しておき，万が一envコマンドが無かったり，スクリプト言語のインタープリターが存在しなければ，自分でインストールしたりシンボリックリンクを貼ればよいだろう。

Shebangにおける引数

以下のようにshebang行にオプションや引数を書くことがある。

#!/bin/sh -eu

#!/usr/bin/env python

ここで問題になるのが，これらのオプションや引数がどう解釈されるかだ。

POSIX規格では，ファイルの先頭2バイトが#!である場合，ファイル1行目のそれ以降の文字は「インタープリター名として扱う」としか記載されておらず，オプションや引数がある場合にどうなるかは書かれていない。

例えば，shebangに以下のように書いた場合を考える。

#!/bin/sh -e -u

この場合，以下の5パターンが考えられる。

期待するのは全てオプションとして認識されること（表の2番目）だ。しかし，Ububntu 16.04では3番目の挙動をした。つまり，引数-e -uが空白を含めた1個（"-e -u"）として認識されてしまった。

この挙動については，Linux Programmer’s Manualのexecveのマニュアルに書かれている。以下のコマンドでも閲覧できる。

man execve

さらに，上記マニュアルのNOTESを確認すると以下の記載がある。

つまり，Linuxでは引数を全体で1個として扱う（表の3番目）が，他の実装では最初の空白を終端（表の4番目）とみなしたり，複数の引数を受け付ける（表の2番目）こともありえる。

元々，POSIX規格にはshebang行の引数については言及がないので，表の1番目の#!以降が空白を含めて丸ごとインタープリターとみなしてしまっても問題ないように解釈できる。このため，どの環境でも動作させるには，基本的にはshebangには引数を書かず，書いたとしてもshebang行における引数は1個までにすべきだろう。

ショートオプションであれば，グループ化できるので以下のようにまとめればよい。

#!/bin/sh -eu

スクリプト言語をenv経由で実行する場合は，envコマンドの引数としてスクリプト言語のインタープリターを指定してしまっているので，残念だがオプションの指定は諦めるしかない。

#!/usr/bin/env python     # OK
#!/usr/bin/env python -v  # NG

本の虫: Shebangという謎な事実上業界標準について

Shebang直後の空白

シェルスクリプトなどを見ていると，以下のようにshebang#!の直後に空白が置かれているshebang行を見かけることがある。

#! /bin/sh

あまりみかけない記述なので，ただの打ち間違いか，Webブラウザの表示や書籍の組版の文字間隔の調整でそうみえているだけだと思っていたのだが，どうやらこのように書く流派が存在するらしい。

このことについては以下のページでの議論とそこから辿れるURLからことの経緯がよくわかる。

unix – #! /bin/sh で、 ! の後にスペースを空けることに理由はあるか – スタック・オーバーフロー

発端としては，GNU autoconfのチュートリアル文書において，「4.2BSDでは先頭4バイト”#! /”をマジックナンバーとして読むのでスペースが必要」と記載されていたためだ。しかし，この記述は誤りで，実際は空白はオプション扱いであり，新しい版のGNU autoconfの文書では修正されている。

さらに，問題の4.1 BSDにおいてもソースコード上でshebangの直後に空白が必要となる修正は入っておらず，空白がなければ動作しない実装が存在したという事実も確認できない。Shebangの直後に空白を入れなければならないというのは，あくまで噂や都市伝説でしかない。

これらの信頼性の欠ける情報に従うべきでないという理由とともに，POSIX規格の観点からも，#!の直後に空白をいれるべきでない。

理由は，#!以降の文字を空白を含めてインタープリターのパスとして認識してもPOSIX定義上の動作としてなんらおかしくないからだ。

まず，POSIXにおけるshebangによるインタープリターの起動メカニズムはexecl()のマニュアルの以下の1文のみで定義されている。

ここでは，ファイルの1行目の#!以降の文字をインタプリターのファイル名とみなすとだけ書かれており，POSIXではこれ以上に詳しいルールはなく，引数の扱いがどうなるかなども実装依存となる。

さらに，以下の事実からPOSIXの定義だけだと，Shebangの直後に空白をおくと，相対パス" /bin/sh"でインタープリターが指定されたと解釈することもできる。

1. Shebangは相対パスも有効，実際にshを./testに配置してShebangを相対パス#!test/shで書いたシェルスクリプトに記述したコマンドps -p $$ -o args=で確認可能。
2. 名前が空白1個のディレクトリも有効なパス（mkdir ' '）。

実際には，空白を含むパスを指定するとコマンドが見つからない。

bash: ./test.sh: /test/bin/sh: bad interpreter: No such file or directory

しかし，POSIXの定義上，#!以降の残りを空白や引数丸ごと単一コマンドとみなしても，挙動として問題ない。

このPOSIX規格の解釈上の曖昧さをなくすために，shebangの直後に空白をいれるべきでない。常に#!/bin/shのように#!の直後に空白を入れずにshebang行を書こう。

シェルスクリプトへのsetuid

最後の問題はセキュリティに関するものだ。ファイルのアクセス権限として，セットユーザーID（setuid）がある。この属性のついたファイルはそのファイルの所有者（通常はroot）の権限で実行できる。

setuidの利点はroot権限のパスワードを教えることなくroot権限でしか行えない作業を行える点だ。例えば，passwdコマンドで自分のログインパスワードを変更する場合や，mountコマンドでデバイスを接続する場合は，本来ならroot権限のファイルを操作する必要がある。しかし，これのコマンドにはsetuid属性があるので，root権限のパスワードをしらなくても通常ユーザーのまま実行できる。

setuidをファイルに設定するには以下のコマンドで行う。

chmod u+s file

処理内容が限定される場合には便利だが，一時的にroot権限を与えてしまうため，セキュリティ上の危険性がある。

実際にシェルスクリプトにsetuid属性がある場合の脆弱性を狙った攻撃が過去には行われたらしい。

このことは，以下で言及されている。

• 「詳解シェルスクリプト」の「15.4 Setuid Shell Scripts: A Bad Idea」
• 「bashクックブック」の「レシピ14.2 インタープリタスプーフィングの回避」
• Unix – Frequently Asked Questions (4/7) [Frequent posting]Section – How can I get setuid shell scripts to work?
• 上記の日本語訳：UNIX FAQ LIST #4.7
• The Whole Story on #! /usr/bin/ksh Perderabo – Tips and Tutorials – Unix Linux Forums

上記のUnix FAQで説明されている2個の事例を紹介する。

#!/bin/sh

cd /tmp
ln /etc/setuid_script -i
PATH=.
-i

/bin/sh -i

#!/bin/sh -

cd /tmp
ln /etc/setuid_script temp
nice -20 temp &
mv my_script temp

nice -20 /bin/sh - temp

if [ $(id -u) != 0 ]; then
 echo "Please run as root user!" >&2
 exit 1
fi

#!/bin/sh -p