【RHEL】#!/bin/bash の意味とは？シェルスクリプト1行目の「シバン」を徹底解説

今回は、Linuxのシェルスクリプトを書く際に必ず目にする「#!/bin/bash」という記述について、その意味と重要性を徹底的に解説します。

シェルスクリプトを学び始めた方であれば、「なぜスクリプトの1行目にこの記述が必要なのか？」「書かなくても動くことがあるのはなぜ？」といった疑問を持ったことがあるのではないでしょうか。

この記事では、単なる「おまじない」として覚えるのではなく、Linuxカーネルの仕組みから理解することで、より深い知識を身につけていただけます。トラブルシューティングや実務でのベストプラクティスまで網羅していますので、ぜひ最後までお読みください。

1. シバン（Shebang）とは何か？基本的な意味と役割
2. なぜ1行目に書く必要があるのか？カーネルの仕組みから理解する
3. 様々なシバンの書き方と使い分け
4. bash と sh とその他シェルの違い
5. シバンを書かないとどうなるか
1. 5-1. シバンなしでも動作するケース
2. 5-2. シバンなしで問題が起きるケース
6. 実行権限（chmod +x）との関係
1. 6-1. 実行権限とシバンの関係
2. 6-2. 実行権限がない場合の挙動
7. よくあるミスとトラブルシューティング
8. 実務でのベストプラクティス
まとめ

1. シバン（Shebang）とは何か？基本的な意味と役割

1-1. シバンの定義

シェルスクリプトの1行目に記述される「#!/bin/bash」は、シバン（Shebang） または シェバン と呼ばれます。他にも「ハッシュバン（Hashbang）」という呼び方もあります。

#!/bin/bash
echo "Hello, World!"

この「#!」という2文字の組み合わせが「シバン」の正体です。「#」はシャープまたはハッシュ、「!」はバン（Bang）と読むため、合わせて「シバン」と呼ばれるようになりました。

1-2. シバンの役割

シバンの最も重要な役割は、「このスクリプトをどのインタープリタ（プログラム）で実行するか」をシステムに伝えることです。

例えば「#!/bin/bash」と書いた場合、「このスクリプトは /bin/bash（Bashシェル）を使って実行してください」という指示になります。

これにより、以下のようなメリットがあります。

スクリプト実行時に、どのシェルで解釈するか明確になる
異なるシェル環境でも意図した動作を保証できる
シェルスクリプト以外（Python、Perl等）でも同じ仕組みで実行可能

1-3. シバンの構文ルール

シバンには厳密な構文ルールがあります。

#!インタープリタのパス [オプション]

重要なポイント：

必ずファイルの1行目に記述する（2行目以降では機能しない）
「#!」の前に空白や文字を入れない
「#!」の後に続くパスは絶対パスで指定する
「#!」とパスの間のスペースは省略可能だが、入れても動作する

#!/bin/bash      # OK：標準的な書き方
#! /bin/bash     # OK：スペースがあっても動作する
# !/bin/bash     # NG：「#」と「!」の間にスペースがあると認識されない

2. なぜ1行目に書く必要があるのか？カーネルの仕組みから理解する

2-1. スクリプト実行時に何が起きているのか

シバンの動作を正しく理解するには、Linuxカーネルがスクリプトをどのように実行するかを知る必要があります。

ターミナルで「./script.sh」のようにスクリプトを実行すると、以下のプロセスが発生します。

【実行の流れ】

シェルが execve() システムコールを発行
カーネルがファイルの先頭2バイトを読み取る
先頭が「#!」であれば、続くパスをインタープリタとして認識
カーネルが指定されたインタープリタを起動し、スクリプトファイルを引数として渡す
インタープリタがスクリプトの内容を解釈・実行

2-2. マジックナンバーとしての「#!」

Linuxカーネルは、ファイルの種類を判別するために「マジックナンバー」という仕組みを使用しています。ファイルの先頭数バイトを読み取り、その値によってファイル形式を識別します。

マジックナンバー	ファイル形式
0x7F 0x45 0x4C 0x46	ELF実行ファイル
0x23 0x21 (#!)	スクリプトファイル
0x89 0x50 0x4E 0x47	PNG画像

「#!」はASCIIコードで「0x23 0x21」となり、カーネルはこれを検出すると「これはスクリプトファイルだ」と判断します。

2-3. なぜ1行目でなければならないのか

カーネルはファイルの先頭2バイトのみをチェックします。そのため、シバンが2行目以降にあると、カーネルは「#!」を検出できず、スクリプトとして認識しません。

# これはコメントです
#!/bin/bash        # ← 2行目にあるため、シバンとして機能しない
echo "Hello"

この場合、カーネルは1行目の「# 」（0x23 0x20）を読み取り、「#!」ではないため、スクリプトファイルとして認識しません。

3. 様々なシバンの書き方と使い分け

3-1. 代表的なシバンの種類

用途に応じて、様々なシバンの書き方があります。

#!/bin/bash          # Bashシェルで実行
#!/bin/sh            # POSIXシェルで実行
#!/usr/bin/env bash  # 環境変数PATHからbashを検索して実行
#!/bin/zsh           # Zシェルで実行
#!/bin/dash          # Dashシェルで実行
#!/usr/bin/python3   # Python3で実行
#!/usr/bin/perl      # Perlで実行

3-2. #!/bin/bash と #!/bin/sh の違い

初心者が最も混乱しやすいのが「#!/bin/bash」と「#!/bin/sh」の違いです。

#!/bin/sh の特徴：

POSIX標準に準拠したシェルを指定
多くのLinuxディストリビューションで /bin/sh は別のシェルへのシンボリックリンク
移植性が高いスクリプトを書く際に使用

各ディストリビューションでの /bin/sh の実体：

ディストリビューション	/bin/sh の実体
Ubuntu / Debian	dash
RHEL / CentOS / Fedora	bash
Alpine Linux	busybox ash
macOS	zsh（Catalina以降）

確認方法：

$ ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Mar 10 12:00 /bin/sh -> dash

重要な注意点：
「#!/bin/sh」を指定した場合、Bash固有の機能（配列、[[ ]] 条件式など）は使用できません。POSIX準拠の構文のみを使用する必要があります。

3-3. #!/usr/bin/env bash を使う理由

「#!/usr/bin/env bash」という書き方もよく見かけます。これは env コマンドを経由してbashを起動する方法です。

#!/usr/bin/env bash
echo "Hello from bash"

この書き方のメリット：

環境変数PATHからインタープリタを検索する
- bashが /bin/bash 以外の場所にある環境でも動作する
- 例：一部のUnix系OSでは /usr/local/bin/bash にインストールされる
移植性が向上する
- 異なるシステム間でスクリプトを共有しやすい

この書き方のデメリット：

envコマンドのパスが異なる可能性
- ほとんどのシステムで /usr/bin/env だが、保証はない
オプションを渡しにくい
- 一部のシステムでは #!/usr/bin/env bash -e のようなオプション指定が動作しない
セキュリティ上の考慮
- PATH環境変数が改ざんされると、意図しないプログラムが実行される可能性

4. bash と sh とその他シェルの違い

4-1. シェルの種類と系譜

Linuxで使用できるシェルには多くの種類があり、それぞれに特徴があります。

Bourneシェル系：

sh (Bourne Shell)：1977年に開発された元祖シェル
bash (Bourne Again Shell)：shを拡張した最も普及しているシェル
dash (Debian Almquist Shell)：軽量・高速なPOSIX準拠シェル

C シェル系：

csh (C Shell)：C言語に似た構文を持つシェル
tcsh：cshを拡張したシェル

その他：

zsh (Z Shell)：bashとtcshの機能を統合した高機能シェル
fish (Friendly Interactive Shell)：ユーザーフレンドリーさを重視したシェル

4-2. bash固有の機能（sh では使えない機能）

「#!/bin/bash」と「#!/bin/sh」では、使える機能に違いがあります。以下はbash固有の機能の例です。

配列：

#!/bin/bash
# bashでは配列が使える
fruits=("apple" "banana" "orange")
echo ${fruits[1]}  # banana

拡張条件式 [[ ]]：

#!/bin/bash
# bashでは [[ ]] が使える
if [[ $string =~ ^[0-9]+$ ]]; then
    echo "数字です"
fi

プロセス置換：

#!/bin/bash
# bashではプロセス置換が使える
diff <(ls dir1) <(ls dir2)

ブレース展開：

#!/bin/bash
# bashではブレース展開が使える
echo {1..5}     # 1 2 3 4 5
echo {a..e}     # a b c d e

4-3. 互換性を意識したスクリプト作成

移植性の高いスクリプトを書く場合は、POSIX準拠の構文を使用することが推奨されます。

bash固有の書き方	POSIX準拠の書き方
`[[ $a == $b ]]`	`[ "$a" = "$b" ]`
`source file.sh`	`. file.sh`
`function func() {}`	`func() {}`
`echo -e "hello\n"`	`printf "hello\n"`

5. シバンを書かないとどうなるか

5-1. シバンなしでも動作するケース

実は、シバンを書かなくてもスクリプトが動作する場合があります。

# シバンなしのスクリプト
echo "Hello, World!"

動作するケース：

明示的にシェルを指定して実行

$ bash script.sh    # bashが直接スクリプトを読み込む
$ sh script.sh      # shが直接スクリプトを読み込む

sourceコマンドで実行

$ source script.sh  # 現在のシェルで実行
$ . script.sh       # 同上

5-2. シバンなしで問題が起きるケース

しかし、シバンがないと以下のような問題が発生する可能性があります。

問題1：直接実行時のエラー

$ chmod +x script.sh
$ ./script.sh

シバンがない場合、カーネルはスクリプトとして認識できず、現在のシェルがフォールバックとして実行を試みます。このとき、現在のシェルとスクリプトの想定するシェルが異なると、予期しないエラーが発生します。

問題2：cronジョブでの実行失敗

cronで実行する場合、シバンがないとエラーになることがあります。

# crontab 設定例
0 * * * * /home/user/script.sh  # シバンがないと失敗する可能性

問題3：異なるシェル環境での動作不良

ログインシェルがzshのユーザーが、bash構文で書かれたシバンなしスクリプトを実行すると、zshとして解釈されエラーになる場合があります。

6. 実行権限（chmod +x）との関係

6-1. 実行権限とシバンの関係

スクリプトを「./script.sh」の形式で直接実行するには、2つの条件が必要です。

実行権限が付与されていること
シバンが正しく設定されていること

# 実行権限を付与
$ chmod +x script.sh

# 実行権限の確認
$ ls -l script.sh
-rwxr-xr-x 1 user user 45 Dec 17 10:00 script.sh

6-2. 実行権限がない場合の挙動

$ ./script.sh
bash: ./script.sh: Permission denied

ただし、実行権限がなくても以下の方法で実行可能です。

$ bash script.sh  # bashに直接読み込ませる

この場合、bashがスクリプトファイルを「読み込む」だけなので、読み取り権限があれば実行できます。

7. よくあるミスとトラブルシューティング

7-1. 改行コードの問題

Windowsで作成したスクリプトをLinuxで実行すると、以下のエラーが発生することがあります。

$ ./script.sh
/bin/bash^M: bad interpreter: No such file or directory

これは、Windowsの改行コード（CRLF：\r\n）が原因です。

解決方法：

# dos2unix コマンドで変換
$ dos2unix script.sh

# または sed で変換
$ sed -i 's/\r$//' script.sh

7-2. パスの間違い

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

指定したインタープリタのパスが存在しない場合、このエラーが発生します。

確認方法：

# bashのパスを確認
$ which bash
/usr/bin/bash

$ type bash
bash is /usr/bin/bash

7-3. BOM（Byte Order Mark）の問題

UTF-8のBOM付きでファイルを保存すると、シバンが正しく認識されません。

確認方法：

$ file script.sh
script.sh: UTF-8 Unicode (with BOM) text

解決方法：

# BOMを除去
$ sed -i '1s/^\xEF\xBB\xBF//' script.sh

8. 実務でのベストプラクティス

8-1. 推奨されるシバンの選び方

用途	推奨シバン
汎用的なシステム管理スクリプト	`#!/bin/bash`
最大限の移植性が必要	`#!/bin/sh`（POSIX準拠構文で記述）
複数環境で共有するスクリプト	`#!/usr/bin/env bash`
高速な起動が求められる	`#!/bin/dash`

8-2. シバン直後に書くべきオプション

堅牢なスクリプトを書くために、シバンの直後に以下のオプションを設定することが推奨されます。

#!/bin/bash
set -euo pipefail

それぞれのオプションがなぜ必要なのか、具体例を交えて解説します。

-e オプション（errexit）：エラー時に即座に終了

設定しない場合の危険性：

デフォルトでは、コマンドがエラーで終了しても、スクリプトは次の行を実行し続けます。これは予期しない動作や被害の拡大を招く可能性があります。

#!/bin/bash
# -e なしの危険な例

cd /var/log/myapp       # ディレクトリが存在しない場合、エラーになるが続行される
rm -rf *                # カレントディレクトリ（意図しない場所）のファイルが削除される！

上記の例では、cd コマンドが失敗しても rm -rf * が実行されてしまい、意図しないディレクトリのファイルが削除される危険があります。

-e を設定した場合：

#!/bin/bash
set -e

cd /var/log/myapp       # エラーが発生するとここでスクリプトが終了
rm -rf *                # cd が失敗した場合、この行は実行されない

-e オプションを設定すると、cd コマンドが失敗した時点でスクリプトが終了するため、後続の危険なコマンドは実行されません。

-u オプション（nounset）：未定義変数の使用をエラーにする

設定しない場合の危険性：

デフォルトでは、未定義の変数は空文字列として扱われます。これはタイプミスや変数名の間違いによる重大な事故を引き起こす可能性があります。

#!/bin/bash
# -u なしの危険な例

BACKUP_DIR="/home/user/backups"
# タイプミス：BACKUP_DIR ではなく BACKUPDIR と書いてしまった
rm -rf ${BACKUPDIR}/*   # $BACKUPDIR は未定義なので空文字列になる
                        # 結果として "rm -rf /*" が実行される危険性！

この例では、変数名のタイプミスにより rm -rf /* が実行され、システム全体のファイルが削除される可能性があります。

-u を設定した場合：

#!/bin/bash
set -u

BACKUP_DIR="/home/user/backups"
rm -rf ${BACKUPDIR}/*   # エラー：BACKUPDIR: unbound variable
                        # スクリプトはここで終了し、rm は実行されない

-u オプションを設定すると、未定義の変数を参照した時点でエラーになり、スクリプトが終了します。タイプミスによる事故を未然に防ぐことができます。

-o pipefail オプション：パイプラインのエラーを検出

設定しない場合の問題：

デフォルトでは、パイプラインの終了ステータスは最後のコマンドの終了ステータスになります。途中のコマンドが失敗しても検出できません。

#!/bin/bash
set -e  # -e だけでは不十分

# 存在しないファイルを grep しようとする（エラー）が、wc -l は成功する
cat /nonexistent/file.txt | grep "pattern" | wc -l
echo "処理が完了しました"  # パイプの途中でエラーがあっても、ここが実行される

この例では、cat コマンドが失敗してもパイプライン全体の終了ステータスは wc -l の成功（0）になるため、-e を設定していてもスクリプトは続行されます。

-o pipefail を設定した場合：

#!/bin/bash
set -eo pipefail

# パイプラインのいずれかのコマンドが失敗すると、全体が失敗とみなされる
cat /nonexistent/file.txt | grep "pattern" | wc -l  # cat の失敗でスクリプト終了
echo "処理が完了しました"  # この行は実行されない

-o pipefail を設定すると、パイプライン内のいずれかのコマンドが失敗した場合、パイプライン全体の終了ステータスが失敗になります。-e と組み合わせることで、パイプライン内のエラーも確実に検出できます。

3つのオプションを組み合わせる理由

これら3つのオプションは、それぞれ異なる種類のエラーを検出します。

オプション	検出するエラー
-e	コマンドの実行失敗
-u	未定義変数の参照
-o pipefail	パイプライン途中のエラー

単独では防げないエラーも、組み合わせることで堅牢なスクリプトになります。本番環境で使用するスクリプトでは、必ずこの3つを設定することを強く推奨します。

#!/bin/bash
set -euo pipefail

# これで安全なスクリプトの土台ができました

8-3. スクリプトのテンプレート

実務で使える堅牢なスクリプトのテンプレートを紹介します。

#!/bin/bash
set -euo pipefail

#===============================================
# スクリプト名: script_name.sh
# 説明: スクリプトの説明をここに記載
# 作成日: 2024-XX-XX
# 作成者: Your Name
#===============================================

# 定数定義
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly SCRIPT_NAME="$(basename "$0")"

# メイン処理
main() {
    echo "処理を開始します"
    # ここに処理を記述
    echo "処理が完了しました"
}

# スクリプト実行
main "$@"

まとめ

この記事では、シェルスクリプトの1行目に書く「#!/bin/bash」（シバン）について、その意味から実務でのベストプラクティスまで詳しく解説しました。

重要なポイントをおさらいしましょう。

シバンは「どのインタープリタでスクリプトを実行するか」を指定する仕組み
カーネルがファイル先頭の「#!」をマジックナンバーとして認識するため、必ず1行目に記述する
「#!/bin/bash」と「#!/bin/sh」では使える機能が異なる
移植性を重視する場合は「#!/usr/bin/env bash」や POSIX準拠構文を検討する
実行権限の付与と正しいシバンの設定がセットで必要

シバンを正しく理解することで、より堅牢で移植性の高いシェルスクリプトが書けるようになります。ぜひ実務でも意識して活用してください。