私が見たほとんどのシェルスクリプト（自分で書いていないスクリプトを除く）で、シバンがに設定されていることに気付きました#!/bin/sh。これは古いスクリプトでは本当に驚かないが、かなり新しいスクリプトでもそうだ。

好むための何らかの理由がある/bin/sh以上は、/bin/bash以来、bash十年以上前にうまくいって、多くのLinuxやBSDマシン上で、かなり多くの遍在し、多くの場合、デフォルト？

1. デフォルトではbashを出荷しないシステムがあります（例：FreeBSD）。
2. bashがインストールされていても、にない場合があり/binます。
3. ほとんどの単純なスクリプトはbashを必要としません。
4. POSIXシェルを使用する方が移植性が高く、スクリプトはさまざまなシステムで実行されます。

（Debian関連：Ubuntu、Mintなど）Linuxのほとんどのシステムスクリプトは、これらのシステムのデフォルトの/ bin / shである高速ダッシュで実行するように記述されています。理由は2つあります。

• システムの速度。ダッシュのコードが小さいほど、読み込みが速くなり、実行も速くなります。シェルスクリプトのプログラマーに多少の（小さな？）追加の労力（コスト）をかけます。

• セキュリティ。シェルの多様性は、バグに対する回復力に役立ちます。デフォルトのシェルにはこのような脆弱性がなかったため、Debianシステムはほとんどshellshockに対して脆弱ではありませんでした。

実際、Bashはより強力で、コーディングを容易にする要素がはるかに多いため、ユーザーのデフォルトのシェルです。またsh、Mac OS のデフォルト（/ bin / shからリンクされているもの）です。ただし、bashというリンク名で呼び出すと、shposix準拠のシェルとして起動します。

他の人たちは、Bourne Againシェルがデフォルトであり、どこにでもあるという質問の前提がまったく間違っていると指摘しています。

それに加えて、シェルスクリプトの解釈にBourne Againシェル以外の何かを使用することには、確かに十分な理由があります。これらの理由は、長年にわたってUbuntuとDebianの大きなプロジェクトをやる気にさせ、システムの初期化（System 5の多くのシェルスクリプトであったrc）とパッケージのインストール/削除によって、多くのシェルスクリプトを実行するようにしました。 Bourne Again シェルの代わりのDebian Almquistシェル。

簡単に言えば、Bourne Againシェルは、インタラクティブな機能がそのまま詰まっていますが、POSIX準拠のシェルスクリプトの最速のシェルインタープリターではありません。したがって、シェルスクリプトをPOSIXに準拠させ、Debian Almquistシェルなどのより軽量なプログラムで解釈できるようにすると、システムのパフォーマンスが向上します。（最終的に、DebianはAlmquistシェルにわずかな調整を加えて、単純に深すぎて広く埋め込まれ、削除するには役に立たないいくつかの非POSIXシェル構成のサポートを追加する必要がありました。）

その結果、ブートストラップのパフォーマンスが大幅に向上しました。

そのため、考慮すべきシェルには2つの異なるクラスがあります。

• アカウントデータベース内のユーザーの対話型ログインシェルとして構成されている、派手な対話型機能をすべて備えたシェル。
• シェルスクリプトプログラムによってスクリプトインタープリターとして使用される、多くのスクリプトを迅速に解釈するシェル。

これを「優先する/bin/sh」と言うのは簡単すぎます。Debianには、実際には少なくとも2つの目標がありました。

1. Debian Almquistシェル、Zシェル（POSIXモード）、Bourne Againシェル（POSIXモード）、MirBSD Kornシェルなどを使用している管理者に直面して/bin/sh、…

   1. …スクリプトを可能な限り移植可能にし、/bin/shマッピング先を切り替えても問題が発生しないようにしました。または

   2. …移植性のないスクリプトを作成して、単にそのマップを期待するのではなく、正しいインタープリタープログラムをターゲットにします/bin/sh。

2. DebianのAlmquistがためにデフォルトのマッピングをシェル作っていた/bin/shので、それらのスクリプトこと、代わりのBourneシェルのだった POSIX準拠（または、より適切に、Debianポリシーマニュアルに準拠）がより迅速に実行しました。

そしてもちろん、一度これに取り組むと、さらに多くのことができます。そのようなの同類の効率のトレードオフを考慮するように/bin/trueし、/usr/bin/clearシェルスクリプトやコンパイルされたプログラムです。しかし、幸いなことに、これはこの答えの範囲を超えています。☺

もちろん、これはまったく新しいものではなく、Unix固有のものでもありません。戻る世紀の変わり目の前に、私はそのDOCOで、この非常に分裂を説明するとの違いを指摘、書いて、両方の「インタラクティブ」と「非対話型」の味に来たコマンドラインインタプリタを公表COMSPECし、OS2_SHELL環境変数を。同様に、DebianのSystem V rcおよびパッケージのインストール/削除スクリプトのbashismsの削除に関する議論は、1990年代にさかのぼります。

参考文献

• https://superuser.com/a/696310/38062
• https://unix.stackexchange.com/a/193210/5132
• としてダッシュ/bin/sh。Ubuntu wiki。
• としてダッシュ/bin/sh。Debian wiki。
• バシズム。グレッグのウィキ。
• ブライアンM.カールソン（2005-07-29）。ポリシー10.4に関する公共サービスの発表。<1122626433.30217.39.camel@stonewall.crustytoothpaste.ath.cx>。debian-devel。
• ラファエル・ガイサート（2009-04-12）。デフォルトの/ bin / shおよびbashisms-freeアーカイブRGとしてダッシュ。<200904121359.09387.atomo64@gmail.com> debian-devel。
• debian-policy：ダッシュの下で動作するスクリプトが「おそらく」ポリシーに準拠していると述べないでください。Debianバグ＃490604。
• goal-dashのDebianパッケージレポート
• debian-policy：echo -nの使用をやめ、一般的にechoを使用してください。Debianバグ＃490605。
• レベッカ・ソボル（2009-07-29）。 2つのシェルの物語：bashまたはdash。LWN。
• ジャスタス・ペンドルトン（1997-04-22）。パッケージのbash-isms。<E0wJjkL-0001II-00@ryoohki.res.cmu.edu>。debian-devel。
• Jonathan de Boyne Pollard（2000）。「コマンドインタープリターのフロントエンド」。コマンドインタープリターコマンドリファレンス。32ビットコマンドインタープリターのオンラインドキュメント。
• ジョン・チェンバース（1990）。/ bin / trueコマンドと著作権

/ bin / bashではなく/ bin / shを指すシェバンを持つ理由はありますか？

はい。@Marcoの優れた答えは、このことをよく示しています。

私のシバンでは何を使うべきですか？

独自のスクリプトを作成するときは、テストした最も一般的なものにシバンを向ける必要があります。

私のシステム（shCentos 6.6）では、以下にシンボリックリンクされていbashます：

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Dec  2  2014 /bin/sh -> bash

これは#!/bin/bash、スクリプトにバシムがないことを確認しない限り、常にシバンで使用することを意味します。

#!/bin/shあなたにシバンを設定することにより、スクリプトがのすべての実装で動作することを約束していますsh。

これは、スクリプトがbashで動作すると言うよりもはるかに大きな約束です。

次にsh、システムが使用している実装に応じて正しく動作しないスクリプトの例を示します。

#!/bin/sh
n=1
a=$((++n))
echo $n

bashスクリプトを使用すると、印刷されます：

2

dashスクリプトを使用すると、印刷されます：

1

#!/bin/sh何を使用したいのですか？

• スクリプトをチェックしますcheckbashisms-これはすべてのバシムを見つけるわけではないことに注意してください。上記のスクリプトでバシズムが見つかりませんでした
• 別のsh実装を使用してスクリプトをテストします。私は通常、でテストしますがdash、一部のバシズムやダシムがまだすり抜けることができると予想しています。

Ubuntu wiki のDashAsBinShページには、多くの興味深い情報があります。

より強力で人間工学に基づいた言語のスクリプトの代わりにシェルスクリプトを記述する唯一の理由は、インストールされたソフトウェアの不明なセットを持つレガシーシステムへの移植性が他の要因よりも重要である場合です。

/bin/shUnixと呼ばれるすべてのもので利用できる唯一のスクリプトインタープリタです。しかし、/bin/sh非常に多くのレガシーシステムでは、関連するユーティリティはPOSIX.1-1996の「シェルおよびユーティリティ」仕様に準拠していません。標準に準拠したツールは、オプションのアドオンであり、インストールされている/usr/xpg4場所またはそのような非自明な場所です。¹ ポータブルサブセットシェル言語へのスクリプティングは、POSIXシェル言語へのスクリプティングよりも退屈でエラーが発生しやすくなります。（configureあなたが私を信じないなら、いつかAutoconfで生成されたスクリプトを読んでください。セットアップだけであなたを納得させることができます。）

ただし、他のスクリプトインタープリター（Bashなど）がインストールされていると想定できる場合は、より優れたスクリプト言語のインタープリターがインストールされていると想定できます。Perlは、例えば、あるより多くのバッシュがあるよりも利用可能である可能性が高いです。

したがって、スクリプトを記述しないでください。これが#! /bin/bashオプションである場合、より良い言語もオプションであるためです。

¹たとえば、Solaris 10以前では、元のBourneシェルがとして出荷されていました/bin/sh。Solaris 11でksh93に更新されたことがわかりました。

実際に使用する必要があります

#! /bin/env sh

または

#! /bin/env bash

その方法で、そのシステムにインストールする方法でいずれかのシェルを呼び出します。

（たとえば、シングルユーザーの再起動の場合）超安全にするにはsh、を使用しますbash。